<<<<<<< .mine
﻿
<!-- saved from url=(0099)#s7.3.2-javadoc-exception-overrides -->
<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  
  <link rel="stylesheet" type="text/css" href="javaguide.css">
  <script src="https://google-code-prettify.googlecode.com/svn/loader/run_prettify.js" type="text/javascript"></script>
  <link href="http://www.google.com/favicon.ico" type="image/x-icon" rel="shortcut icon">
  <title>Google Java 风格</title></head>
<body>
  <h1>Google Java 风格</h1>
  <div class="change">最后修改于2014年3月21日</div>
<table border="0">
<tbody><tr>
<td>
<dl>
<br>
<dt class="toc1">
<a href="#s1-introduction">1 引言</a>
</dt>
<dd>
<a href="#s1.1-terminology">1.1 术语注解</a>
</dd>
<dd>
<a href="#s1.2-guide-notes">1.2 依据注解</a>
</dd>
<br>
<dt class="toc1">
<a href="#s2-source-file-basics">2 源文件基本部分</a>
</dt>
<dd>
<a href="#s2.1-file-name">2.1 文件名</a>
</dd>
<dd>
<a href="#s2.2-file-encoding">2.2 文件编码：UTF-8</a>
</dd>
<dd>
<a href="#s2.3-special-characters">2.3 特殊字符</a>
</dd>
<dd class="toc3">
<a href="#s2.3.1-whitespace-characters">2.3.1 空白符</a>
</dd>
<dd class="toc3">
<a href="#s2.3.2-special-escape-sequences">2.3.2 特殊的转义符</a>
</dd>
<dd class="toc3">
<a href="#s2.3.3-non-ascii-characters">2.3.3 非ASCII字符</a>
</dd>
<br>
<dt class="toc1">
<a href="#s3-source-file-structure">3 源文件结构</a>
</dt>
<dd>
<a href="#s3.1-copyright-statement">3.1 许可或版权信息，如果有</a>
</dd>
<dd>
<a href="#s3.2-package-statement">3.2 声明包</a>
</dd>
<dd>
<a href="#s3.3-import-statements">3.3 声明引入</a>
</dd>
<dd class="toc3">
<a href="#s3.3.1-wildcard-imports">3.3.1 勿使用通配符引入</a>
</dd>
<dd class="toc3">
<a href="#s3.3.2-import-line-wrapping">3.3.2 不换行</a>
</dd>
<dd class="toc3">
<a href="#s3.3.3-import-ordering-and-spacing">3.3.3 排列与间距</a>
</dd>
<dd>
<a href="#s3.4-class-declaration">3.4 声明类</a>
</dd>
<dd class="toc3">
<a href="#s3.4.1-one-top-level-class">3.4.1 唯一顶层类声明</a>
</dd>
<dd class="toc3">
<a href="#s3.4.2-class-member-ordering">3.4.2 排列类成员</a>
</dd>
</dl>
</td><td>
<dl>
<br>
<dt class="toc1">
<a href="#s4-formatting">4 格式</a>
</dt>
<dd>
<a href="#s4.1-braces">4.1 花括号</a>
</dd>
<dd class="toc3">
<a href="#s4.1.1-braces-always-used">4.1.1 何处花括号可选</a>
</dd>
<dd class="toc3">
<a href="#s4.1.2-blocks-k-r-style">4.1.2 非空块: K &amp; R 样式</a>
</dd>
<dd class="toc3">
<a href="#s4.1.3-braces-empty-blocks">4.1.3 空块: 可以很简洁</a>
</dd>
<dd>
<a href="#s4.2-block-indentation">4.2 块缩进: +2 空格</a>
</dd>
<dd>
<a href="#s4.3-one-statement-per-line">4.3 一行一语句</a>
</dd>
<dd>
<a href="#s4.4-column-limit">4.4 列数限制: 80 or 100</a>
</dd>
<dd>
<a href="#s4.5-line-wrapping">4.5 换行</a>
</dd>
<dd class="toc3">
<a href="#s4.5.1-line-wrapping-where-to-break">4.5.1 何处截断</a>
</dd>
<dd class="toc3">
<a href="#s4.5.2-line-wrapping-indent">4.5.2 缩进连续行至少 +4 空格</a>
</dd>
<dd>
<a href="#s4.6-whitespace">4.6 空白符</a>
</dd>
<dd class="toc3">
<a href="#s4.6.1-vertical-whitespace">4.6.1 垂直空白符</a>
</dd>
<dd class="toc3">
<a href="#s4.6.2-horizontal-whitespace">4.6.2 水平空白符</a>
</dd>
<dd class="toc3">
<a href="#s4.6.3-horizontal-alignment">4.6.3 水平对齐：从不要求</a>
</dd>
<dd>
<a href="#s4.7-grouping-parentheses">4.7 分组括号：推荐</a>
</dd>
<dd>
<a href="#s4.8-specific-constructs">4.8 特殊结构</a>
</dd>
<dd class="toc3">
<a href="#s4.8.1-enum-classes">4.8.1 枚举类</a>
</dd>
<dd class="toc3">
<a href="#s4.8.2-variable-declarations">4.8.2 变量声明</a>
</dd>
<dd class="toc3">
<a href="#s4.8.3-arrays">4.8.3 数组</a>
</dd>
<dd class="toc3">
<a href="#s4.8.4-switch">4.8.4 开关语句</a>
</dd>
<dd class="toc3">
<a href="#s4.8.5-annotations">4.8.5 注解</a>
</dd>
<dd class="toc3">
<a href="#s4.8.6-comments">4.8.6 注释</a>
</dd>
<dd class="toc3">
<a href="#s4.8.7-modifiers">4.8.7 修饰符</a>
</dd>
<dd class="toc3">
<a href="#s4.8.8-numeric-literals">4.8.8 数字符</a>
</dd>
</dl>
</td><td>
<dl>
<br>
<dt class="toc1">
<a href="#s5-naming">5 命名</a>
</dt>
<dd>
<a href="#s5.1-identifier-names">5.1 适用于所有标识符的规则</a>
</dd>
<dd>
<a href="#s5.2-specific-identifier-names">5.2 按标识符类型分类的规则</a>
</dd>
<dd class="toc3">
<a href="#s5.2.1-package-names">5.2.1 命名包</a>
</dd>
<dd class="toc3">
<a href="#s5.2.2-class-names">5.2.2 命名类</a>
</dd>
<dd class="toc3">
<a href="#s5.2.3-method-names">5.2.3 命名方法</a>
</dd>
<dd class="toc3">
<a href="#s5.2.4-constant-names">5.2.4 命名常量</a>
</dd>
<dd class="toc3">
<a href="#s5.2.5-non-constant-field-names">5.2.5 命名非常量字段</a>
</dd>
<dd class="toc3">
<a href="#s5.2.6-parameter-names">5.2.6 命名参数</a>
</dd>
<dd class="toc3">
<a href="#s5.2.7-local-variable-names">5.2.7 命名本地变量</a>
</dd>
<dd class="toc3">
<a href="#s5.2.8-type-variable-names">5.2.8 命名类型变量</a>
</dd>
<dd>
<a href="#s5.3-camel-case">5.3 科莫大小写： 定义</a>
</dd>
<br>
<dt class="toc1">
<a href="#s6-programming-practices">6 编码习惯</a>
</dt>
<dd>
<a href="#s6.1-override-annotation">6.1 @Override：总是采用</a>
</dd>
<dd>
<a href="#s6.2-caught-exceptions">6.2 捕捉到的异常: 别忽略</a>
</dd>
<dd>
<a href="#s6.3-static-members">6.3 静态成员: 使用类修饰</a>
</dd>
<dd>
<a href="#s6.4-finalizers">6.4 Finalizers：别用了</a>
</dd>
<br>
<dt class="toc1">
<a href="#s7-javadoc">7 Javadoc</a>
</dt>
<dd>
<a href="#s7.1-javadoc-formatting">7.1 格式</a>
</dd>
<dd class="toc3">
<a href="#s7.1.1-javadoc-multi-line">7.1.1 一般形式</a>
</dd>
<dd class="toc3">
<a href="#s7.1.2-javadoc-paragraphs">7.1.2 段落</a>
</dd>
<dd class="toc3">
<a href="#s7.1.3-javadoc-at-clauses">7.1.3 分句处</a>
</dd>
<dd>
<a href="#s7.2-summary-fragment">7.2 The summary fragment</a>
</dd>
<dd>
<a href="#s7.3-javadoc-where-required">7.3 何处用到Javadoc </a>
</dd>
<dd class="toc3">
<a href="#s7.3.1-javadoc-exception-self-explanatory">7.3.1 异常: 自我解释方法</a>
</dd>
<dd class="toc3">
<a href="Google Java Style.html">7.3.2 异常: 重载</a>
</dd>
</dl>
</td>
</tr>
</tbody></table>
<div><a name="s1-introduction">
    </a><h2><a name="s1-introduction">1 引言&nbsp;</a><a href="#s1-introduction"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <p>此文档用于<strong> 完整 </strong>定义Google的Java™程序语言源代码的编码规范。一个Java 源文件被描述为<em> 采用Google Style </em>当且仅当它遵循此处的规则。</p><p>如同其它的编码风格指导书一样，风格所涵盖的问题不仅有排版上的审美争议，还有其它类型的约定或编码规范争议，然而本文主要关注那些我们常用的<strong> 不易变的规则 </strong>，并且避免给出可行性(无论是通过人或工具实现)不甚明了的<em> 建议 </em>。
</p><a name="s1.1-terminology">
    </a><h3><a name="s1.1-terminology">1.1 术语注释&nbsp;</a><a href="#s1.1-terminology"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>本文档中, 除非另行说明:</p><ol><li>术语<em> class </em>被统一地用于表达 “通常” 类，枚举类，
接口或注解类型	(<code class="prettyprint lang-java">@interface</code>)。</li><li>术语<em> comment </em>总是指的是<em> 实施 </em>的注释。 我们不使用“文档注释”这个短语，而采用通常术语“Javadoc”。</li></ol><p>在贯穿全文的过程中，其它术语注解会偶尔出现。</p><a name="s1.2-guide-notes">
    </a><h3><a name="s1.2-guide-notes">1.2 依据注解&nbsp;</a><a href="#s1.2-guide-notes"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>本文档中的示例代码是<strong> 非标准的 </strong>。 就是说，虽然这些例子是采用Google Style，但它们并没有说明描述代码<em> 唯一 </em>的风格化方法，示例中作出的可选格式选择不应该强制作为规则。</p><a name="s2-source-file-basics">
    </a><h2><a name="s2-source-file-basics">2 Source file basics&nbsp;</a><a href="#s2-source-file-basics"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <a name="s2.1-file-name">
    </a><h3><a name="s2.1-file-name">2.1 File name&nbsp;</a><a href="#s2.1-file-name"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>The source file name consists of the case-sensitive name of the top-level class it contains,
plus the <code>.java</code> extension.</p><a name="s2.2-file-encoding">
    </a><h3><a name="s2.2-file-encoding">2.2 File encoding: UTF-8&nbsp;</a><a href="#s2.2-file-encoding"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Source files are encoded in <strong>UTF-8</strong>.</p><a name="s2.3-special-characters">
    </a><h3><a name="s2.3-special-characters">2.3 Special characters&nbsp;</a><a href="#s2.3-special-characters"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s2.3.1-whitespace-characters">
    </a><h4><a name="s2.3.1-whitespace-characters">2.3.1 Whitespace characters&nbsp;</a><a href="#s2.3.1-whitespace-characters"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Aside from the line terminator sequence, the <strong>ASCII horizontal space
character</strong> (<strong>0x20</strong>) is the only whitespace character that appears
anywhere in a source file. This implies that:</p><ol><li>All other whitespace characters in string and character literals are escaped.</li><li>Tab characters are <strong>not</strong> used for indentation.</li></ol><a name="s2.3.2-special-escape-sequences">
    </a><h4><a name="s2.3.2-special-escape-sequences">2.3.2 Special escape sequences&nbsp;</a><a href="#s2.3.2-special-escape-sequences"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>For any character that has a special escape sequence
(<code class="prettyprint lang-java">\b</code>,
<code class="prettyprint lang-java">\t</code>,
<code class="prettyprint lang-java">\n</code>,
<code class="prettyprint lang-java">\f</code>,
<code class="prettyprint lang-java">\r</code>,
<code class="prettyprint lang-java">\"</code>,
<code class="prettyprint lang-java">\'</code> and
<code class="prettyprint lang-java">\\</code>), that sequence
is used rather than the corresponding octal
(e.g.&nbsp;<code class="badcode">\012</code>) or Unicode
(e.g.&nbsp;<code class="badcode">\u000a</code>) escape.</p><a name="s2.3.3-non-ascii-characters">
    </a><h4><a name="s2.3.3-non-ascii-characters">2.3.3 Non-ASCII characters&nbsp;</a><a href="#s2.3.3-non-ascii-characters"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>For the remaining non-ASCII characters, either the actual Unicode character
(e.g.&nbsp;<code class="prettyprint lang-java">∞</code>) or the equivalent Unicode escape
(e.g.&nbsp;<code class="prettyprint lang-java">\u221e</code>) is used, depending only on which
makes the code <strong>easier to read and understand</strong>.</p><p class="tip"><strong>Tip:</strong> In the Unicode escape case, and occasionally even when actual
Unicode characters are used, an explanatory comment can be very helpful.</p><p>Examples:</p><table><tbody><tr><th>Example</th><th>Discussion</th></tr><tr><td><code class="prettyprint lang-java">String unitAbbrev = "μs";</code></td><td>Best: perfectly clear even without a comment.</td></tr><tr><td><code class="prettyprint lang-java">String unitAbbrev = "\u03bcs"; // "μs"</code></td><td>Allowed, but there's no reason to do this.</td></tr><tr><td><code class="prettyprint lang-java">String unitAbbrev = "\u03bcs";
      // Greek letter mu, "s"</code></td><td>Allowed, but awkward and prone to mistakes.</td></tr><tr><td><code class="badcode">String unitAbbrev = "\u03bcs";</code></td><td>Poor: the reader has no idea what this is.</td></tr><tr><td><code class="prettyprint lang-java">return '\ufeff' + content;
       // byte order mark</code></td><td>Good: use escapes for non-printable characters, and comment if necessary.</td></tr></tbody></table><p class="tip"><strong>Tip:</strong> Never make your code less readable simply out of fear that
some programs might not handle non-ASCII characters properly. If that should happen, those
programs are <strong>broken</strong> and they must be <strong>fixed</strong>.</p><a name="filestructure"></a><a name="s3-source-file-structure">
    </a>
<h2><a name="s3-source-file-structure">3 源文件结构&nbsp;</a><a href="#s3-source-file-structure"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <div>
      <p>源文件的结构，包括<strong></strong>：</p>
      <ol>
        <li>许可证或者版权信息(如果存在)</li>
        <li>声明包</li>
        <li>声明导入</li>
        <li>唯一顶层类声明</li>
      </ol>
    </div><p><strong>Exactly one blank line</strong> separates each section that is present.</p><a name="s3.1-copyright-statement">
    </a>
    <h3><a name="s3.1-copyright-statement">3.1许可证或者版权信息（如果存在）&nbsp;</a><a href="#s3.1-copyright-statement"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>如果许可证或者版权信息在一个文件中， 它应该放在这里。</p>
    <a name="s3.2-package-statement">
    </a>
    <h3><a name="s3.2-package-statement">3.2 声明包&nbsp;</a><a href="#s3.2-package-statement"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>声明包时<strong>不能换行</strong>。列数限制 (4.4部分,
<a href="#s4.4-column-limit">列数限制: 80 or 100</a>) 在声明包时不适用。</p>
    <a name="imports"></a><a name="s3.3-import-statements">
    </a>
    <h3><a name="s3.3-import-statements">3.3 声明导入&nbsp;</a><a href="#s3.3-import-statements"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s3.3.1-wildcard-imports">
    </a>
    <h4><a name="s3.3.1-wildcard-imports">3.3.1 勿使用通配符导入&nbsp;</a><a href="#s3.3.1-wildcard-imports"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p><strong>通配符的导入</strong>， 静态的或其他的，<strong>都不使用</strong>。</p>
    <a name="s3.3.2-import-line-wrapping">
    </a>
    <h4><a name="s3.3.2-import-line-wrapping">3.3.2 不换行&nbsp;</a><a href="#s3.3.2-import-line-wrapping"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>声明导入时are <strong>不换行</strong>。 列数限制 （ 4.4部分，
<a href="#s4.4-column-limit">列数限制： 80 or 100</a>）在声明导入时不适用。</p>
    <a name="s3.3.3-import-ordering-and-spacing">
    </a><h4><a name="s3.3.3-import-ordering-and-spacing">3.3.3 排列和间距&nbsp;</a><a href="#s3.3.3-import-ordering-and-spacing"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>导入语句被分成以下几组，在这个顺序，每组由一个单一的空行分隔：</p>
    <ol>
      <li>所以的静态导入在单个分组。</li>
      <li><code>com.google</code> 导入
  (仅当此源文件是在 <code>com.google</code> 封装空间)</li>
      <li>第三方导入，每个顶级包一组, 在 ASCII 码中排序
        <ul>
          <li>例如： <code>android</code>, <code>com</code>, <code>junit</code>, <code>org</code>,
    <code>sun</code></li>
        </ul></li>
      <li><code>java</code> 导入</li>
      <li><code>javax</code> 导入</li>
    </ol>
    <p>分组内没有空行，导入的名称出现在ASCII码中排序。 （ <strong>注意:</strong> 这是不一样的导入 <em>声明</em>在
ASCII 码排序；分好的存在使结果不合理。）</p>
    <a name="s3.4-class-declaration">
    </a>
    <h3><a name="s3.4-class-declaration">3.4类声明&nbsp;</a><a href="#s3.4-class-declaration"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="oneclassperfile"></a><a name="s3.4.1-one-top-level-class">
    </a>
    <h4><a name="s3.4.1-one-top-level-class">3.4.1唯一顶层类声明&nbsp;</a><a href="#s3.4.1-one-top-level-class"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>每一个顶级类放在自己的源文件中。</p>
    <a name="s3.4.2-class-member-ordering">
    </a>
    <h4><a name="s3.4.2-class-member-ordering">3.4.2 排序类成员&nbsp;</a><a href="#s3.4.2-class-member-ordering"><img height="21" width="21" src="javaguidelink.png"></a></h4>
  <p>类中成员的排序会对易用性产生很大的影响，但是目前没有唯一的准则来指导如何排序。 不同的类可以对他们的成员做不同的排序。.</p>
    <p>不同的类在对它的成员逻辑排序时什么是最重要的<strong></strong>， 如果问到时它的维护者能够做出说明。例如， 新方法不只是习惯性地添加到类结尾，因为这将产生“按添加日期”排序，这不是一个符合逻辑的排序。</p>
    <a name="overloads"></a><a name="s3.4.2.1-overloads-never-split">
    </a>
    <h5><a name="s3.4.2.1-overloads-never-split">3.4.2.1 重载:从不分开&nbsp;</a><a href="#s3.4.2.1-overloads-never-split"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>当一个类有多个构造函数，或者多个方法具有相同的名字，这些相继出现，中间没有成员。</p>
    <a name="s4-formatting">
    </a><h2><a name="s4-formatting">4 Formatting&nbsp;</a><a href="#s4-formatting"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <p class="terminology"><strong>Terminology Note:</strong> <em>block-like construct</em> refers to
the body of a class, method or constructor. Note that, by Section 4.8.3.1 on
<a href="#s4.8.3.1-array-initializers">array initializers</a>, any array initializer
<em>may</em> optionally be treated as if it were a block-like construct.</p><a name="braces"></a><a name="s4.1-braces">
    </a><h3><a name="s4.1-braces">4.1 Braces&nbsp;</a><a href="#s4.1-braces"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s4.1.1-braces-always-used">
    </a><h4><a name="s4.1.1-braces-always-used">4.1.1 Braces are used where optional&nbsp;</a><a href="#s4.1.1-braces-always-used"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Braces are used with
<code class="prettyprint lang-java">if</code>,
<code class="prettyprint lang-java">else</code>,
<code class="prettyprint lang-java">for</code>,
<code class="prettyprint lang-java">do</code> and
<code class="prettyprint lang-java">while</code> statements, even when the
body is empty or contains only a single statement.</p><a name="s4.1.2-blocks-k-r-style">
    </a><h4><a name="s4.1.2-blocks-k-r-style">4.1.2 Nonempty blocks: K &amp; R style&nbsp;</a><a href="#s4.1.2-blocks-k-r-style"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Braces follow the Kernighan and Ritchie style
("<a href="http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html">Egyptian brackets</a>")
for <em>nonempty</em> blocks and block-like constructs:</p><ul><li>No line break before the opening brace.</li><li>Line break after the opening brace.</li><li>Line break before the closing brace.</li><li>Line break after the closing brace <em>if</em> that brace terminates a statement or the body
  of a method, constructor or <em>named</em> class. For example, there is <em>no</em> line break
  after the brace if it is followed by <code class="prettyprint lang-java">else</code> or a
  comma.</li></ul><p>Example:</p><pre class="prettyprint lang-java">return new MyClass() {
  @Override public void method() {
    if (condition()) {
      try {
        something();
      } catch (ProblemException e) {
        recover();
      }
    }
  }
};
</pre><p>A few exceptions for enum classes are given in Section 4.8.1,
<a href="#s4.8.1-enum-classes">Enum classes</a>.</p><a name="emptyblocks"></a><a name="s4.1.3-braces-empty-blocks">
    </a><h4><a name="s4.1.3-braces-empty-blocks">4.1.3 Empty blocks: may be concise&nbsp;</a><a href="#s4.1.3-braces-empty-blocks"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>An empty block or block-like construct <em>may</em> be closed immediately after it is
opened, with no characters or line break in between
(<code class="prettyprint lang-java">{}</code>), <strong>unless</strong> it is part of a
<em>multi-block statement</em> (one that directly contains multiple blocks:
<code class="prettyprint lang-java">if/else-if/else</code> or
<code class="prettyprint lang-java">try/catch/finally</code>).</p><p>Example:</p><pre class="prettyprint lang-java">  void doNothing() {}
</pre><a name="s4.2-block-indentation">
    </a><h3><a name="s4.2-block-indentation">4.2 Block indentation: +2 spaces&nbsp;</a><a href="#s4.2-block-indentation"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Each time a new block or block-like construct is opened, the indent increases by two
spaces. When the block ends, the indent returns to the previous indent level. The indent level
applies to both code and comments throughout the block. (See the example in Section 4.1.2,
<a href="#s4.1.2-blocks-k-r-style">Nonempty blocks: K &amp; R Style</a>.)</p><a name="s4.3-one-statement-per-line">
    </a><h3><a name="s4.3-one-statement-per-line">4.3 One statement per line&nbsp;</a><a href="#s4.3-one-statement-per-line"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Each statement is followed by a line-break.</p><a name="columnlimit"></a><a name="s4.4-column-limit">
    </a><h3><a name="s4.4-column-limit">4.4 Column limit: 80 or 100&nbsp;</a><a href="#s4.4-column-limit"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>
  Projects are free to choose a column limit of either 80 or 100 characters.

Except as noted below, any line that would exceed this limit must be line-wrapped, as explained in
Section 4.5, <a href="#s4.5-line-wrapping">Line-wrapping</a>.
</p><p><strong>Exceptions:</strong></p><ol><li>Lines where obeying the column limit is not possible (for example, a long URL in Javadoc,
  or a long JSNI method reference).</li><li><code class="prettyprint lang-java">package</code> and
  <code class="prettyprint lang-java">import</code> statements (see Sections
  3.2 <a href="#s3.2-package-statement">Package statement</a> and
  3.3 <a href="#s3.3-import-statements">Import statements</a>).</li><li>Command lines in a comment that may be cut-and-pasted into a shell.</li></ol><a name="s4.5-line-wrapping">
    </a><h3><a name="s4.5-line-wrapping">4.5 Line-wrapping&nbsp;</a><a href="#s4.5-line-wrapping"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p class="terminology"><strong>Terminology Note:</strong> When code that might otherwise legally
occupy a single line is divided into multiple lines, typically to avoid overflowing the column
limit, this activity is called
<em>line-wrapping</em>.</p><p>There is no comprehensive, deterministic formula showing <em>exactly</em> how to line-wrap in
every situation. Very often there are several valid ways to line-wrap the same piece of code.</p><p class="tip"><strong>Tip:</strong> Extracting a method or local variable may solve the problem
without the need to line-wrap.</p><a name="s4.5.1-line-wrapping-where-to-break">
    </a><h4><a name="s4.5.1-line-wrapping-where-to-break">4.5.1 Where to break&nbsp;</a><a href="#s4.5.1-line-wrapping-where-to-break"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>The prime directive of line-wrapping is: prefer to break at a
<strong>higher syntactic level</strong>. Also:</p><ol><li>When a line is broken at a <em>non-assignment</em> operator the break comes <em>before</em>
  the symbol. (Note that this is not the same practice used in Google style for other languages,
  such as C++ and JavaScript.)
    <ul><li>This also applies to the following "operator-like" symbols: the dot separator
      (<code class="prettyprint lang-java">.</code>), the ampersand in type bounds
      (<code class="prettyprint lang-java">&lt;T extends Foo &amp; Bar&gt;</code>), and the pipe in
      catch blocks
      (<code class="prettyprint lang-java">catch (FooException | BarException e)</code>).</li></ul></li><li>When a line is broken at an <em>assignment</em> operator the break typically comes
  <em>after</em> the symbol, but either way is acceptable.
    <ul><li>This also applies to the "assignment-operator-like" colon in an enhanced
      <code class="prettyprint lang-java">for</code> ("foreach") statement.</li></ul></li><li>A method or constructor name stays attached to the open parenthesis
  (<code class="prettyprint lang-java">(</code>) that follows it.</li><li>A comma (<code class="prettyprint lang-java">,</code>) stays attached to the token that
  precedes it.</li></ol><a name="indentation"></a><a name="s4.5.2-line-wrapping-indent">
    </a><h4><a name="s4.5.2-line-wrapping-indent">4.5.2 Indent continuation lines at least +4 spaces&nbsp;</a><a href="#s4.5.2-line-wrapping-indent"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>When line-wrapping, each line after the first (each <em>continuation line</em>) is indented
at least +4 from the original line.</p><p>When there are multiple continuation lines, indentation may be varied beyond +4 as
desired. In general, two continuation lines use the same indentation level if and only if they
begin with syntactically parallel elements.</p><p>Section 4.6.3 on <a href="#s4.6.3-horizontal-alignment">Horizontal alignment</a> addresses
the discouraged practice of using a variable number of spaces to align certain tokens with
previous lines.</p><a name="s4.6-whitespace">
    </a><h3><a name="s4.6-whitespace">4.6 Whitespace&nbsp;</a><a href="#s4.6-whitespace"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s4.6.1-vertical-whitespace">
    </a><h4><a name="s4.6.1-vertical-whitespace">4.6.1 Vertical Whitespace&nbsp;</a><a href="#s4.6.1-vertical-whitespace"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>A single blank line appears:</p><ol><li><em>Between</em> consecutive members (or initializers) of a class: fields, constructors,
  methods, nested classes, static initializers, instance initializers.
  <ul><li><span class="exception"><strong>Exception:</strong> A blank line between two consecutive
    fields (having no other code between them) is optional. Such blank lines are used as needed to
    create <em>logical groupings</em> of fields.</span></li></ul></li><li>Within method bodies, as needed to create <em>logical groupings</em> of statements.</li><li><em>Optionally</em> before the first member or after the last member of the class (neither
  encouraged nor discouraged).</li><li>As required by other sections of this document (such as Section 3.3,
  <a href="#s3.3-import-statements">Import statements</a>).</li></ol><p><em>Multiple</em> consecutive blank lines are permitted, but never required (or encouraged).</p><a name="s4.6.2-horizontal-whitespace">
    </a><h4><a name="s4.6.2-horizontal-whitespace">4.6.2 Horizontal whitespace&nbsp;</a><a href="#s4.6.2-horizontal-whitespace"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Beyond where required by the language or other style rules, and apart from literals, comments and
Javadoc, a single ASCII space also appears in the following places <strong>only</strong>.</p><ol><li>Separating any reserved word, such as
  <code class="prettyprint lang-java">if</code>,
  <code class="prettyprint lang-java">for</code> or
  <code class="prettyprint lang-java">catch</code>, from an open parenthesis
  (<code class="prettyprint lang-java">(</code>)
  that follows it on that line</li><li>Separating any reserved word, such as
  <code class="prettyprint lang-java">else</code> or
  <code class="prettyprint lang-java">catch</code>, from a closing curly brace
  (<code class="prettyprint lang-java">}</code>) that precedes it on that line</li><li>Before any open curly brace
  (<code class="prettyprint lang-java">{</code>), with two exceptions:
  <ul><li><code class="prettyprint lang-java">@SomeAnnotation({a, b})</code> (no space is used)</li><li><code class="prettyprint lang-java">String[][] x = {{"foo"}};</code> (no space is required
    between <code class="prettyprint lang-java">{{</code>, by item 8 below)</li></ul></li><li>On both sides of any binary or ternary operator. This also applies to the following
  "operator-like" symbols:
  <ul><li>the ampersand in a conjunctive type bound:
    <code class="prettyprint lang-java">&lt;T extends Foo &amp; Bar&gt;</code></li><li>the pipe for a catch block that handles multiple exceptions:
    <code class="prettyprint lang-java">catch (FooException | BarException e)</code></li><li>the colon (<code class="prettyprint lang-java">:</code>) in an enhanced
    <code class="prettyprint lang-java">for</code> ("foreach") statement</li></ul></li><li>After <code class="prettyprint lang-java">,:;</code> or the closing parenthesis
  (<code class="prettyprint lang-java">)</code>) of a cast</li><li>On both sides of the double slash (<code class="prettyprint lang-java">//</code>) that
  begins an end-of-line comment. Here, multiple spaces are allowed, but not required.</li><li>Between the type and variable of a declaration:
  <code class="prettyprint lang-java">List&lt;String&gt; list</code></li><li><em>Optional</em> just inside both braces of an array initializer
  <ul><li><code class="prettyprint lang-java">new int[] {5, 6}</code> and
    <code class="prettyprint lang-java">new int[] { 5, 6 }</code> are both valid</li></ul></li></ol><p class="note"><strong>Note:</strong> This rule never requires or forbids additional space at the
start or end of a line, only <em>interior</em> space.</p><a name="s4.6.3-horizontal-alignment">
    </a><h4><a name="s4.6.3-horizontal-alignment">4.6.3 Horizontal alignment: never required&nbsp;</a><a href="#s4.6.3-horizontal-alignment"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p class="terminology"><strong>Terminology Note:</strong> <em>Horizontal alignment</em> is the
practice of adding a variable number of additional spaces in your code with the goal of making
certain tokens appear directly below certain other tokens on previous lines.</p><p>This practice is permitted, but is <strong>never required</strong> by Google Style. It is not
even required to <em>maintain</em> horizontal alignment in places where it was already used.</p><p>Here is an example without alignment, then using alignment:</p><pre class="prettyprint lang-java">private int x; // this is fine
private Color color; // this too

private int   x;      // permitted, but future edits
private Color color;  // may leave it unaligned
</pre><p class="tip"><strong>Tip:</strong> Alignment can aid readability, but it creates problems for
future maintenance.  Consider a future change that needs to touch just one line. This change may
leave the formerly-pleasing formatting mangled, and that is <strong>allowed</strong>. More often
it prompts the coder (perhaps you) to adjust whitespace on nearby lines as well, possibly
triggering a cascading series of reformattings. That one-line change now has a "blast radius."
This can at worst result in pointless busywork, but at best it still corrupts version history
information, slows down reviewers and exacerbates merge conflicts.</p><a name="parentheses"></a><a name="s4.7-grouping-parentheses">
    </a><h3><a name="s4.7-grouping-parentheses">4.7 Grouping parentheses: recommended&nbsp;</a><a href="#s4.7-grouping-parentheses"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Optional grouping parentheses are omitted only when author and reviewer agree that there is no
reasonable chance the code will be misinterpreted without them, nor would they have made the code
easier to read. It is <em>not</em> reasonable to assume that every reader has the entire Java
operator precedence table memorized.</p><a name="s4.8-specific-constructs">
    </a><h3><a name="s4.8-specific-constructs">4.8 Specific constructs&nbsp;</a><a href="#s4.8-specific-constructs"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s4.8.1-enum-classes">
    </a><h4><a name="s4.8.1-enum-classes">4.8.1 Enum classes&nbsp;</a><a href="#s4.8.1-enum-classes"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>After each comma that follows an enum constant, a line-break is optional.</p><p>An enum class with no methods and no documentation on its constants may optionally be formatted
as if it were an array initializer (see Section 4.8.3.1 on
<a href="#s4.8.3.1-array-initializers">array initializers</a>).</p><pre class="prettyprint lang-java">private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }
</pre><p>Since enum classes <em>are classes</em>, all other rules for formatting classes apply.</p><a name="localvariables"></a><a name="s4.8.2-variable-declarations">
    </a><h4><a name="s4.8.2-variable-declarations">4.8.2 Variable declarations&nbsp;</a><a href="#s4.8.2-variable-declarations"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <a name="s4.8.2.1-variables-per-declaration">
    </a><h5><a name="s4.8.2.1-variables-per-declaration">4.8.2.1 One variable per declaration&nbsp;</a><a href="#s4.8.2.1-variables-per-declaration"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Every variable declaration (field or local) declares only one variable: declarations such as
<code class="badcode">int a, b;</code> are not used.</p><a name="s4.8.2.2-variables-limited-scope">
    </a><h5><a name="s4.8.2.2-variables-limited-scope">4.8.2.2 Declared when needed, initialized as soon as
possible&nbsp;</a><a href="#s4.8.2.2-variables-limited-scope"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Local variables are <strong>not</strong> habitually declared at the start of their containing
block or block-like construct. Instead, local variables are declared close to the point they are
first used (within reason), to minimize their scope. Local variable declarations typically have
initializers, or are initialized immediately after declaration.</p><a name="s4.8.3-arrays">
    </a><h4><a name="s4.8.3-arrays">4.8.3 Arrays&nbsp;</a><a href="#s4.8.3-arrays"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <a name="s4.8.3.1-array-initializers">
    </a><h5><a name="s4.8.3.1-array-initializers">4.8.3.1 Array initializers: can be "block-like"&nbsp;</a><a href="#s4.8.3.1-array-initializers"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Any array initializer may <em>optionally</em> be formatted as if it were a "block-like
construct." For example, the following are all valid (<strong>not</strong> an exhaustive
list):</p><pre class="prettyprint lang-java">new int[] {           new int[] {
  0, 1, 2, 3            0,
}                       1,
                        2,
new int[] {             3,
  0, 1,               }
  2, 3
}                     new int[]
                          {0, 1, 2, 3}
</pre><a name="s4.8.3.2-array-declarations">
    </a><h5><a name="s4.8.3.2-array-declarations">4.8.3.2 No C-style array declarations&nbsp;</a><a href="#s4.8.3.2-array-declarations"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>The square brackets form a part of the <em>type</em>, not the variable:
<code class="prettyprint lang-java">String[] args</code>, not
<code class="badcode">String args[]</code>.</p><a name="s4.8.4-switch">
    </a><h4><a name="s4.8.4-switch">4.8.4 Switch statements&nbsp;</a><a href="#s4.8.4-switch"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p class="terminology"><strong>Terminology Note:</strong> Inside the braces of a
<em>switch block</em> are one or more <em>statement groups</em>. Each statement group consists of
one or more <em>switch labels</em> (either <code class="prettyprint lang-java">case FOO:</code> or
<code class="prettyprint lang-java">default:</code>), followed by one or more statements.</p><a name="s4.8.4.1-switch-indentation">
    </a><h5><a name="s4.8.4.1-switch-indentation">4.8.4.1 Indentation&nbsp;</a><a href="#s4.8.4.1-switch-indentation"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>As with any other block, the contents of a switch block are indented +2.</p><p>After a switch label, a newline appears, and the indentation level is increased +2, exactly as
if a block were being opened. The following switch label returns to the previous indentation
level, as if a block had been closed.</p><a name="fallthrough"></a><a name="s4.8.4.2-switch-fall-through">
    </a><h5><a name="s4.8.4.2-switch-fall-through">4.8.4.2 Fall-through: commented&nbsp;</a><a href="#s4.8.4.2-switch-fall-through"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Within a switch block, each statement group either terminates abruptly (with a
<code class="prettyprint lang-java">break</code>,
<code class="prettyprint lang-java">continue</code>,
<code class="prettyprint lang-java">return</code> or thrown exception), or is marked with a comment
to indicate that execution will or <em>might</em> continue into the next statement group. Any
comment that communicates the idea of fall-through is sufficient (typically
<code class="prettyprint lang-java">// fall through</code>). This special comment is not required in
the last statement group of the switch block. Example:</p><pre class="prettyprint lang-java">switch (input) {
  case 1:
  case 2:
    prepareOneOrTwo();
    // fall through
  case 3:
    handleOneTwoOrThree();
    break;
  default:
    handleLargeNumber(input);
}
</pre><a name="s4.8.4.3-switch-default">
    </a><h5><a name="s4.8.4.3-switch-default">4.8.4.3 The default case is present&nbsp;</a><a href="#s4.8.4.3-switch-default"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Each switch statement includes a <code class="prettyprint lang-java">default</code> statement
group, even if it contains no code.</p><a name="annotations"></a><a name="s4.8.5-annotations">
    </a><h4><a name="s4.8.5-annotations">4.8.5 Annotations&nbsp;</a><a href="#s4.8.5-annotations"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Annotations applying to a class, method or constructor appear immediately after the
documentation block, and each annotation is listed on a line of its own (that is, one annotation
per line). These line breaks do not constitute line-wrapping (Section
4.5, <a href="#s4.5-line-wrapping">Line-wrapping</a>), so the indentation level is not
increased. Example:</p><pre class="prettyprint lang-java">@Override
@Nullable
public String getNameIfPresent() { ... }
</pre><p class="exception"><strong>Exception:</strong> A <em>single</em> parameterless annotation
<em>may</em> instead appear together with the first line of the signature, for example:</p><pre class="prettyprint lang-java">@Override public int hashCode() { ... }
</pre><p>Annotations applying to a field also appear immediately after the documentation block, but in
this case, <em>multiple</em> annotations (possibly parameterized) may be listed on the same line;
for example:</p><pre class="prettyprint lang-java">@Partial @Mock DataLoader loader;
</pre><p>There are no specific rules for formatting parameter and local variable annotations.</p><a name="comments"></a><a name="s4.8.6-comments">
    </a><h4><a name="s4.8.6-comments">4.8.6 Comments&nbsp;</a><a href="#s4.8.6-comments"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <a name="s4.8.6.1-block-comment-style">
    </a><h5><a name="s4.8.6.1-block-comment-style">4.8.6.1 Block comment style&nbsp;</a><a href="#s4.8.6.1-block-comment-style"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Block comments are indented at the same level as the surrounding code. They may be in
<code class="prettyprint lang-java">/* ... */</code> style or
<code class="prettyprint lang-java">// ...</code> style. For multi-line
<code class="prettyprint lang-java">/* ... */</code> comments, subsequent lines must start with
<code>*</code> aligned with the <code>*</code> on the previous line.</p><pre class="prettyprint lang-java">/*
 * This is          // And so           /* Or you can
 * okay.            // is this.          * even do this. */
 */
</pre><p>Comments are not enclosed in boxes drawn with asterisks or other characters.</p><p class="tip"><strong>Tip:</strong> When writing multi-line comments, use the
<code class="prettyprint lang-java">/* ... */</code> style if you want automatic code formatters to
re-wrap the lines when necessary (paragraph-style). Most formatters don't re-wrap lines in
<code class="prettyprint lang-java">// ...</code> style comment blocks.</p><a name="modifiers"></a><a name="s4.8.7-modifiers">
    </a><h4><a name="s4.8.7-modifiers">4.8.7 Modifiers&nbsp;</a><a href="#s4.8.7-modifiers"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Class and member modifiers, when present, appear in the order
recommended by the Java Language Specification:
</p><pre>public protected private abstract static final transient volatile synchronized native strictfp
</pre><a name="s4.8.8-numeric-literals">
    </a><h4><a name="s4.8.8-numeric-literals">4.8.8 Numeric Literals&nbsp;</a><a href="#s4.8.8-numeric-literals"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p><code>long</code>-valued integer literals use an uppercase <code>L</code> suffix, never
lowercase (to avoid confusion with the digit <code>1</code>). For example, <code>3000000000L</code>
rather than <code class="badcode">3000000000l</code>.</p><a name="naming"></a><a name="s5-naming">
    </a>
<h2><a name="s5-naming">5 命名&nbsp;</a><a href="#s5-naming"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <a name="s5.1-identifier-names">
    </a>
    <h3><a name="s5.1-identifier-names">5.1 适用于所有标识符的规则&nbsp;</a><a href="#s5.1-identifier-names"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>标识符 仅使用ASCII码的字母和数字，and in two cases noted below, underscores。<span srcinfo="0:3" dstinfo="0:1" paragraphname="paragraph0" id="ouHighlight__0_3TO0_1">因此</span><span srcinfo="5:8" dstinfo="2:3" paragraphname="paragraph0" id="ouHighlight__5_8TO2_3">每个</span><span srcinfo="10:14" dstinfo="4:5" paragraphname="paragraph0" id="ouHighlight__10_14TO4_5">有效</span><span id="noHighlight_0.891926120268181">的</span><span srcinfo="16:25" dstinfo="7:9" paragraphname="paragraph0" id="ouHighlight__16_25TO7_9">标识符</span><span srcinfo="27:30" dstinfo="10:11" paragraphname="paragraph0" id="ouHighlight__27_30TO10_11">名称</span><span srcinfo="32:41" dstinfo="12:13" paragraphname="paragraph0" id="ouHighlight__32_41TO12_13">匹配</span><span srcinfo="50:56" dstinfo="14:15" paragraphname="paragraph0" id="ouHighlight__50_56TO14_15">正则</span><span srcinfo="58:67" dstinfo="16:18" paragraphname="paragraph0" id="ouHighlight__58_67TO16_18">表达式</span> <code>\w+</code>。</p>
    <p> 在 Google 风格中特殊的前缀和后缀，像这些例子中 <code class="badcode">name_</code>,
<code class="badcode">mName</code>, <code class="badcode">s_name</code> and
<code class="badcode">kName</code>，都不使用。</p>
    <a name="s5.2-specific-identifier-names">
    </a>
    <h3><a name="s5.2-specific-identifier-names">5.2 标识符类型分类规则&nbsp;</a><a href="#s5.2-specific-identifier-names"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s5.2.1-package-names">
    </a>
    <h4><a name="s5.2.1-package-names">5.2.1 命名包&nbsp;</a><a href="#s5.2.1-package-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>包的名称全部使用小写字母，连续的单词只是串在一起（不使用下划线）。例如， <code>com.example.deepspace</code>，不是
<code class="badcode">com.example.deepSpace</code> 或者
<code class="badcode">com.example.deep_space</code>.</p>
    <a name="s5.2.2-class-names">
    </a>
    <h4><a name="s5.2.2-class-names">5.2.2 命名类&nbsp;</a><a href="#s5.2.2-class-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>类的名称都写在 <a href="#s5.3-camel-case">UpperCamelCase</a>中。</p>
    <p>类的名称是常用的名词或者名词短语。例如，
<code class="prettyprint lang-java">Character</code> 或者
<code class="prettyprint lang-java">ImmutableList</code>。接口名称也可能是名称或名词短语 （例如， <code class="prettyprint lang-java">List</code>），但是也可能 有时候 是用 形容词或者形容词短语 （例如，
<code class="prettyprint lang-java">Readable</code>）。</p>
    <p>没有明确的规定或者公认的规范命名注释类型。</p>
  <p><em>测试</em>类的命名以正在测试的类的名称做开头，以 <code class="prettyprint lang-java">Test</code>结尾。例如， F<code class="prettyprint lang-java">HashTest</code>或<code class="prettyprint lang-java">HashIntegrationTest</code>。</p>
    <a name="s5.2.3-method-names">
    </a>
<h4><a name="s5.2.3-method-names">5.2.3 命名方法&nbsp;</a><a href="#s5.2.3-method-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>方法的名称都写在<a href="#s5.3-camel-case">lowerCamelCase</a>中。</p>
    <p>方法的名称通常是动词或动词短语。 例如，
<code class="prettyprint lang-java">sendMessage</code>或者<code class="prettyprint lang-java">stop</code>。</p>
    <p>在 JUnit<em>测试</em>方法 名称中可能使用下划线去间隔名称的不同逻辑组成。一种典型的模式是 <code>test<i>&lt;MethodUnderTest&gt;</i>_<i>&lt;state&gt;</i></code>，例如 <code class="prettyprint lang-java">testPop_emptyStack</code>。这不是 一个正确的方法去命名测试方法。</p>
    <a name="constants"></a><a name="s5.2.4-constant-names">
    </a>
<h4><a name="s5.2.4-constant-names">5.2.4 命名常量&nbsp;</a><a href="#s5.2.4-constant-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>常量的命名像这样 <code class="prettyprint lang-java">CONSTANT_CASE</code>：所有字母大写， 单词之间用下划线分隔。但是什么才是常量 ，十分确定的？</p>
    <p>每个常数是一个静态的最终字段，但不是所有的静态最终字段都是常量。在选择常量之前，要考虑字段是否真的 <em>感觉就像</em>  一个常量。例如， 如果一个实例的任何观察状态改变，那它几乎肯定不是一个常量。 仅仅 <em>打算</em> 从不变化的对象一般是不够。例如：</p>
    <pre class="prettyprint lang-java">// Constants
static final int NUMBER = 5;
static final ImmutableList&lt;String&gt; NAMES = ImmutableList.of("Ed", "Ann");
static final Joiner COMMA_JOINER = Joiner.on(',');  // because Joiner is immutable
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }

// Not constants
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final Set&lt;String&gt; mutableCollection = new HashSet&lt;String&gt;();
static final ImmutableSet&lt;SomeMutableType&gt; mutableElements = ImmutableSet.of(mutable);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};
</pre>
  <p>这些名称通常是名词或名词短语。</p>
    <a name="s5.2.5-non-constant-field-names">
  </a>
<h4><a name="s5.2.5-non-constant-field-names">5.2.5 命名非常量字段&nbsp;</a><a href="#s5.2.5-non-constant-field-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>非常量字段名称（静态或别的）都写在 <a href="#s5.3-camel-case">lowerCamelCase</a>.</p>
    <p>这些名称通常是名词或名词短语。  例如，
<code class="prettyprint lang-java">computedValues</code> 或
<code class="prettyprint lang-java">index</code>。</p>
    <a name="s5.2.6-parameter-names">
    </a>
    <h4><a name="s5.2.6-parameter-names">5.2.6命名参数&nbsp;</a><a href="#s5.2.6-parameter-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>参数名称都写在<a href="#s5.3-camel-case">lowerCamelCase</a>中。</p>
    <p><span srcinfo="30:35" dstinfo="0:0" paragraphname="paragraph0" id="ouHighlight__30_35TO0_0">应</span><span srcinfo="40:46" dstinfo="1:2" paragraphname="paragraph0" id="ouHighlight__40_46TO1_2">避免</span><span srcinfo="0:12" dstinfo="3:6" paragraphname="paragraph0" id="ouHighlight__0_12TO3_6">一个字符</span><span id="noHighlight_0.11923266784287989">的</span><span srcinfo="14:22" dstinfo="10:11" paragraphname="paragraph0" id="ouHighlight__14_22TO10_11">参数</span><span id="noHighlight_0.7692683101631701">的</span><span srcinfo="24:28" dstinfo="13:14" paragraphname="paragraph0" id="ouHighlight__24_28TO13_14">名称</span><span id="noHighlight_0.658939826535061">。</span></p>
    <a name="s5.2.7-local-variable-names">
    </a>
    <h4><a name="s5.2.7-local-variable-names">5.2.7 命名本地变量&nbsp;</a><a href="#s5.2.7-local-variable-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>本地变量的名称写在 <a href="#s5.3-camel-case">lowerCamelCase</a>中， 并且能缩写比其它类型名称更自由。</p>
    <p><span srcinfo="30:35" dstinfo="0:0" paragraphname="paragraph0" id="ouHighlight__30_35TO0_0">应</span><span srcinfo="40:46" dstinfo="1:2" paragraphname="paragraph0" id="ouHighlight__40_46TO1_2">避免</span><span srcinfo="0:12" dstinfo="3:6" paragraphname="paragraph0" id="ouHighlight__0_12TO3_6">一个字符</span><span id="noHighlight_0.11923266784287989">的</span><span srcinfo="14:22" dstinfo="10:11" paragraphname="paragraph0" id="ouHighlight__14_22TO10_11">参数</span><span id="noHighlight_0.7692683101631701">的</span><span srcinfo="24:28" dstinfo="13:14" paragraphname="paragraph0" id="ouHighlight__24_28TO13_14">名称</span>，除了临时变量和循环变量。</p>
    <p>Even when final and immutable, local variables are not considered to be constants, and should not
be styled as constants.</p><a name="s5.2.8-type-variable-names">
    </a>
<h4><a name="s5.2.8-type-variable-names">5.2.8 命名类型变量 &nbsp;</a><a href="#s5.2.8-type-variable-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>每一个类型变量 的命名两种方法任取其一：</p>
    <ul><li>一种是首字母大写， 后面可以添加单个数字 （例如
  <code class="prettyprint lang-java">E</code>，<code class="prettyprint lang-java">T</code>，
  <code class="prettyprint lang-java">X</code>，<code class="prettyprint lang-java">T2</code>）
  </li><li>一种名称使用类的命名方法（参考5.2.2章，
  <a href="#s5.2.2-class-names">命名类</a>）， 再加上大写字母
  <code class="prettyprint lang-java">T</code> （例如：
  <code class="prettyprint lang-java">RequestT</code>，
  <code class="prettyprint lang-java">FooBarT</code>)。</li></ul>
    <a name="acronyms"></a><a name="camelcase"></a><a name="s5.3-camel-case">
    </a>
    <h3><a name="s5.3-camel-case">5.3 科莫大小写：定义&nbsp;</a><a href="#s5.3-camel-case"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>有时还有不止一个合理的方式，将英语短语转化为 科莫大小写，例如当首字母缩写词或不常见的构造 像 &quot;IPv6&quot;或&quot;iOS&quot;的存在。为了提高可预见性，Google风格指定以下 （几乎） 确定的方案。<br>
    </p>
    <p>以散文形式名称开始：<br>
    </p>
    <ol>
      <li><span srcinfo="0:6" dstinfo="0:1" paragraphname="paragraph1" id="ouHighlight__0_6TO0_1">转换</span><span srcinfo="19:20" dstinfo="2:2" paragraphname="paragraph1" id="ouHighlight__19_20TO2_2">为</span><span srcinfo="22:26" dstinfo="3:3" paragraphname="paragraph1" id="ouHighlight__22_26TO3_3">纯</span><span id="noHighlight_0.8251943488139659"> </span><span srcinfo="28:32" dstinfo="5:9" paragraphname="paragraph1" id="ouHighlight__28_32TO5_9">ASCII</span><span id="noHighlight_0.5151416100561619"> 的短语</span><span id="noHighlight_0.32333659240975976">，</span><span srcinfo="34:36" dstinfo="16:16" paragraphname="paragraph1" id="ouHighlight__34_36TO16_16">并</span><span srcinfo="38:43" dstinfo="17:18" paragraphname="paragraph1" id="ouHighlight__38_43TO17_18">删除</span><span srcinfo="45:47" dstinfo="19:20" paragraphname="paragraph1" id="ouHighlight__45_47TO19_20">任何</span><span srcinfo="49:59" dstinfo="21:22" paragraphname="paragraph1" id="ouHighlight__49_59TO21_22">撇号</span><span id="noHighlight_0.4210728828329593">。</span> 例如，“Müller's algorithm”有可能成为“Muellers algorithm”。</li>
      <li>把这一结果分成若干个词， <span srcinfo="31:39" dstinfo="9:10" paragraphname="paragraph0" id="ouHighlight__31_39TO9_10">剔除</span><span srcinfo="41:42" dstinfo="11:11" paragraphname="paragraph0" id="ouHighlight__41_42TO11_11"></span><span srcinfo="44:49" dstinfo="12:13" paragraphname="paragraph0" id="ouHighlight__44_49TO12_13">空格</span><span srcinfo="51:53" dstinfo="14:14" paragraphname="paragraph0" id="ouHighlight__51_53TO14_14">和</span><span srcinfo="55:57" dstinfo="15:16" paragraphname="paragraph0" id="ouHighlight__55_57TO15_16">任何</span><span srcinfo="59:67" dstinfo="17:18" paragraphname="paragraph0" id="ouHighlight__59_67TO17_18">剩余</span><span id="noHighlight_0.8846981073729694">的</span><span srcinfo="69:79" dstinfo="20:21" paragraphname="paragraph0" id="ouHighlight__69_79TO20_21">标点</span><span id="noHighlight_0.17793782730586827">（通常是连字符）。</span>
        <ul><li><em>Recommended:</em> if any word already has a conventional camel-case appearance in common
    usage, split this into its constituent parts (e.g., "AdWords" becomes "ad&nbsp;words"). Note
    that a word such as "iOS" is not really in camel case <em>per se</em>; it defies <em>any</em>
    convention, so this recommendation does not apply.</li></ul></li><li>Now lowercase <em>everything</em> (including acronyms), then uppercase only the first
  character of:
  <ul><li>... each word, to yield <em>upper camel case</em>, or</li><li>... each word except the first, to yield <em>lower camel case</em></li></ul></li><li>Finally, join all the words into a single identifier.</li></ol>
    <p><br>
    需要注意的是原词的外壳几乎完全忽略。例如：</p>
    <table><tbody><tr><th>Prose form</th><th>Correct</th><th>Incorrect</th></tr><tr><td>"XML HTTP request"</td><td><code class="prettyprint lang-java">XmlHttpRequest</code></td><td><code class="badcode">XMLHTTPRequest</code></td></tr><tr><td>"new customer ID"</td><td><code class="prettyprint lang-java">newCustomerId</code></td><td><code class="badcode">newCustomerID</code></td></tr><tr><td>"inner stopwatch"</td><td><code class="prettyprint lang-java">innerStopwatch</code></td><td><code class="badcode">innerStopWatch</code></td></tr><tr><td>"supports IPv6 on iOS?"</td><td><code class="prettyprint lang-java">supportsIpv6OnIos</code></td><td><code class="badcode">supportsIPv6OnIOS</code></td></tr><tr><td>"YouTube importer"</td><td><code class="prettyprint lang-java">YouTubeImporter</code><br><code class="prettyprint lang-java">YoutubeImporter</code>*</td><td></td></tr></tbody></table><p>*Acceptable, but not recommended.</p><p class="note"><strong>Note:</strong> Some words are ambiguously hyphenated in the English
language: for example "nonempty" and "non-empty" are both correct, so the method names
<code class="prettyprint lang-java">checkNonempty</code> and
<code class="prettyprint lang-java">checkNonEmpty</code> are likewise both correct.</p><a name="s6-programming-practices">
    </a><h2><a name="s6-programming-practices">6 Programming Practices&nbsp;</a><a href="#s6-programming-practices"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <a name="s6.1-override-annotation">
    </a><h3><a name="s6.1-override-annotation">6.1 @Override: always used&nbsp;</a><a href="#s6.1-override-annotation"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>A method is marked with the <code class="prettyprint lang-java">@Override</code> annotation
whenever it is legal.  This includes a class method overriding a superclass method, a class method
implementing an interface method, and an interface method respecifying a superinterface
method.</p><p class="exception"><strong>Exception:</strong><code class="prettyprint lang-java">@Override</code> may be omitted when the parent method is
<code class="prettyprint lang-java">@Deprecated</code>.</p><a name="caughtexceptions"></a><a name="s6.2-caught-exceptions">
    </a><h3><a name="s6.2-caught-exceptions">6.2 Caught exceptions: not ignored&nbsp;</a><a href="#s6.2-caught-exceptions"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Except as noted below, it is very rarely correct to do nothing in response to a caught
exception. (Typical responses are to log it, or if it is considered "impossible", rethrow it as an
<code class="prettyprint lang-java">AssertionError</code>.)</p><p>When it truly is appropriate to take no action whatsoever in a catch block, the reason this is
justified is explained in a comment.</p><pre class="prettyprint lang-java">try {
  int i = Integer.parseInt(response);
  return handleNumericResponse(i);
} catch (NumberFormatException ok) {
  // it's not numeric; that's fine, just continue
}
return handleTextResponse(response);
</pre><p class="exception"><strong>Exception:</strong> In tests, a caught exception may be ignored
without comment <em>if</em> it is named <code class="prettyprint lang-java">expected</code>. The
following is a very common idiom for ensuring that the method under test <em>does</em> throw an
exception of the expected type, so a comment is unnecessary here.</p><pre class="prettyprint lang-java">try {
  emptyStack.pop();
  fail();
} catch (NoSuchElementException expected) {
}
</pre><a name="s6.3-static-members">
    </a><h3><a name="s6.3-static-members">6.3 Static members: qualified using class&nbsp;</a><a href="#s6.3-static-members"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>When a reference to a static class member must be qualified, it is qualified with that class's
name, not with a reference or expression of that class's type.</p><pre class="prettyprint lang-java">Foo aFoo = ...;
Foo.aStaticMethod(); // good
<span class="badcode">aFoo.aStaticMethod();</span> // bad
<span class="badcode">somethingThatYieldsAFoo().aStaticMethod();</span> // very bad
</pre><a name="finalizers"></a><a name="s6.4-finalizers">
    </a><h3><a name="s6.4-finalizers">6.4 Finalizers: not used&nbsp;</a><a href="#s6.4-finalizers"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>It is <strong>extremely rare</strong> to override <code class="prettyprint lang-java">Object.finalize</code>.</p><p class="tip"><strong>Tip:</strong> Don't do it. If you absolutely must, first read and understand
<a href="http://books.google.com/books?isbn=8131726592"><em>Effective Java</em></a>
Item 7, "Avoid Finalizers," very carefully, and <em>then</em> don't do it.</p><a name="javadoc"></a><a name="s7-javadoc">
    </a><h2><a name="s7-javadoc">7 Javadoc&nbsp;</a><a href="#s7-javadoc"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <a name="s7.1-javadoc-formatting">
    </a>
    <h3><a name="s7.1-javadoc-formatting">7.1 格式&nbsp;</a><a href="#s7.1-javadoc-formatting"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s7.1.1-javadoc-multi-line">
    </a>
    <h4><a name="s7.1.1-javadoc-multi-line">7.1.1 一般样式&nbsp;</a><a href="#s7.1.1-javadoc-multi-line"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Javadoc 的基本格式是本例所示：</p>
    <pre class="prettyprint lang-java">/**
 * Multiple lines of Javadoc text are written here,
 * wrapped normally...
 */
public int method(String p1) { ... }
</pre>
    <p><span srcinfo="0:1" dstinfo="0:0" paragraphname="paragraph0" id="ouHighlight__0_1TO0_0">......或</span><span srcinfo="3:4" dstinfo="1:1" paragraphname="paragraph0" id="ouHighlight__3_4TO1_1">在</span><span srcinfo="23:29" dstinfo="2:3" paragraphname="paragraph0" id="ouHighlight__23_29TO2_3">下例</span><span id="noHighlight_0.11366995167918503">中</span><span srcinfo="11:21" dstinfo="5:7" paragraphname="paragraph0" id="ouHighlight__11_21TO5_7">为单行格式：</span></p>
    <pre class="prettyprint lang-java">/** An especially short bit of Javadoc. */
</pre>
  <p>基本格式是一直被认可的。当没有分句存在时可以使用单行格式，和 整体Javadoc 块 （包括注释标记） 一起可以放在单独的一行。</p>
    <a name="s7.1.2-javadoc-paragraphs">
  </a>
<h4><a name="s7.1.2-javadoc-paragraphs">7.1.2 段落 &nbsp;</a><a href="#s7.1.2-javadoc-paragraphs"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>一个空白行 —— 就是，一行中只有向上对齐的星号（<code>*</code>）—出现在两个段落之间， 在一组f "at-clauses"（如果存在）之前。 Each paragraph but the first has <code>&lt;p&gt;</code> immediately before the first word,
with no space after.</p>
    <a name="s7.1.3-javadoc-at-clauses">
    </a>
<h4><a name="s7.1.3-javadoc-at-clauses">7.1.3 分句处&nbsp;</a><a href="#s7.1.3-javadoc-at-clauses"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>任何标准的“at-clauses”使用的显示顺序 <code>@param</code>，
<code>@return</code>， <code>@throws</code>， <code>@deprecated</code>， 而这四种类型不会出现一个空的描述。当在分句不适合在单行上， 在  <code>@</code>处继续缩进四行（或更多的）空间.</p>
    <a name="s7.2-summary-fragment">
    </a> 
    <h3><a name="s7.2-summary-fragment">7.2 The summary fragment&nbsp;</a><a href="#s7.2-summary-fragment"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Javadoc中的每个类和成员首先有一个简要的summary fragment。这个片段是非常重要的：它是出现在某些情况下，如类和方法索引中的一部分。</p>
    <p>这是一个片段——一个名词短语或动词短语，不是一个完整的句子。它不是以 <code class="badcode">A {@code Foo} is a...</code>，或 
<code class="badcode">This method returns...</code>，也没形成一个完整的命令行如 <code class="badcode">Save the record.</code>。然而，该片段用大写字母强调好像它是一个完整的句子。</p>
    <p class="tip"><strong>Tip:</strong> A common mistake is to write simple Javadoc in the form
<code class="badcode">/** @return the customer ID */</code>. This is incorrect, and should be
changed to <code class="prettyprint lang-java">/** Returns the customer ID. */</code>.</p><a name="s7.3.3-javadoc-optional"></a><a name="s7.3-javadoc-where-required">
    </a>
<h3><a name="s7.3-javadoc-where-required">7.3 何处用到Javadoc&nbsp;</a><a href="#s7.3-javadoc-where-required"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p><em>至少</em>，Javadoc目前为每一个
<code class="prettyprint lang-java">public</code> 类，和每一个
<code class="prettyprint lang-java">public</code> 或
<code class="prettyprint lang-java">protected</code>成员<span id="noHighlight_0.16078259982168674">，除了</span><span srcinfo="7:9" dstinfo="2:3" paragraphname="paragraph2" id="ouHighlight__7_9TO2_3">少数</span><span srcinfo="11:20" dstinfo="4:5" paragraphname="paragraph2" id="ouHighlight__11_20TO4_5">例外</span><span id="noHighlight_0.17944350675679743">在</span><span srcinfo="28:32" dstinfo="7:8" paragraphname="paragraph2" id="ouHighlight__28_32TO7_8">下面</span><span srcinfo="22:26" dstinfo="9:10" paragraphname="paragraph2" id="ouHighlight__22_26TO9_10">注明</span><span id="noHighlight_0.013337768847122788">。</span></p>
    <p>其它的类和成员  <em>根据需要</em> 还有Javadoc。<span srcinfo="0:7" dstinfo="0:1" paragraphname="paragraph2" id="ouHighlight__0_7TO0_1">每当</span>填写注释<span srcinfo="35:39" dstinfo="6:6" paragraphname="paragraph2" id="ouHighlight__35_39TO6_6">将</span><span srcinfo="44:50" dstinfo="7:8" paragraphname="paragraph2" id="ouHighlight__44_50TO7_8">用于</span><span srcinfo="52:57" dstinfo="9:10" paragraphname="paragraph2" id="ouHighlight__52_57TO9_10">定义</span><span srcinfo="63:69" dstinfo="11:12" paragraphname="paragraph2" id="ouHighlight__63_69TO11_12">整体</span><span id="noHighlight_0.8075590091757476">的</span><span srcinfo="71:77" dstinfo="14:15" paragraphname="paragraph2" id="ouHighlight__71_77TO14_15">目的</span><span srcinfo="79:80" dstinfo="16:16" paragraphname="paragraph2" id="ouHighlight__79_80TO16_16">或</span><span srcinfo="94:94" dstinfo="17:17" paragraphname="paragraph2" id="ouHighlight__94_94TO17_17">一</span><span srcinfo="96:100" dstinfo="18:18" paragraphname="paragraph2" id="ouHighlight__96_100TO18_18">类</span><span srcinfo="91:92" dstinfo="19:19" paragraphname="paragraph2" id="ouHighlight__91_92TO19_19">的</span><span srcinfo="82:89" dstinfo="20:21" paragraphname="paragraph2" id="ouHighlight__82_89TO20_21">行为</span>，方法或字段，<span srcinfo="52:58" dstinfo="6:7" paragraphname="paragraph4" id="ouHighlight__52_58TO6_7">而不是</span><span srcinfo="41:42" dstinfo="8:9" paragraphname="paragraph4" id="ouHighlight__41_42TO8_9">作为</span><span id="noHighlight_0.15451227477751672"> </span><span srcinfo="44:50" dstinfo="11:17" paragraphname="paragraph4" id="ouHighlight__44_50TO11_17">Javadoc</span><span id="noHighlight_0.47021514480002224"> </span><span srcinfo="33:39" dstinfo="19:20" paragraphname="paragraph4" id="ouHighlight__33_39TO19_20">写入</span><span srcinfo="22:28" dstinfo="21:22" paragraphname="paragraph4" id="ouHighlight__22_28TO21_22">注释</span><span id="noHighlight_0.27892226865515113">。</span>（这样更一致，更友好（易读）） </p>
    <a name="s7.3.1-javadoc-exception-self-explanatory">
    </a>
    <h4><a name="s7.3.1-javadoc-exception-self-explanatory">7.3.1 异常：自我解释方法&nbsp;</a><a href="#s7.3.1-javadoc-exception-self-explanatory"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Javadoc 是非强制的对于 "simple, obvious" 方法来说， 如 
<code class="prettyprint lang-java">getFoo</code>，在这中情况下这里 <em>的的确确</em> 是没有别的去说除了 "Returns the foo"。</p>
    <p class="note"><strong>Important:</strong> it is not appropriate to cite this exception to justify
omitting relevant information that a typical reader might need to know. For example, for a method
named <code class="prettyprint lang-java">getCanonicalName</code>, don't omit its documentation
(with the rationale that it would say only
<code class="badcode">/** Returns the canonical name. */</code>) if a typical reader may have no idea
what the term "canonical name" means!</p><a name="s7.3.2-javadoc-exception-overrides">
    </a>
<h4><a name="s7.3.2-javadoc-exception-overrides">7.3.2 异常：重载</a><a href="Google Java Style.html"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p><span srcinfo="0:6" dstinfo="0:6" paragraphname="paragraph0" id="ouHighlight__0_6TO0_6">avadoc</span><span id="noHighlight_0.7382809852715582"> </span><span srcinfo="8:13" dstinfo="8:9" paragraphname="paragraph0" id="ouHighlight__8_13TO8_9">并非</span><span srcinfo="15:20" dstinfo="10:11" paragraphname="paragraph0" id="ouHighlight__15_20TO10_11">总是</span><span srcinfo="22:28" dstinfo="12:13" paragraphname="paragraph0" id="ouHighlight__22_28TO12_13">存在</span><span srcinfo="33:33" dstinfo="14:14" paragraphname="paragraph0" id="ouHighlight__33_33TO14_14">一</span><span id="noHighlight_0.33469880907796323">种</span><span srcinfo="47:55" dstinfo="16:17" paragraphname="paragraph0" id="ouHighlight__47_55TO16_17">重写</span><span srcinfo="59:67" dstinfo="18:20" paragraphname="paragraph0" id="ouHighlight__59_67TO18_20">父类</span><span srcinfo="69:74" dstinfo="21:22" paragraphname="paragraph0" id="ouHighlight__69_74TO21_22">方法</span><span id="noHighlight_0.9282335317693651">的</span><span srcinfo="35:40" dstinfo="24:25" paragraphname="paragraph0" id="ouHighlight__35_40TO24_25">方法</span><span id="noHighlight_0.5059154618065804">。</span></p>
</div>  <hr>
  <div class="change">Last changed: March 21, 2014</div>


=======
﻿<!-- adapted from:   google-styleguide project >
<!-- source: https://google-styleguide.googlecode.com/svn/trunk/javaguide.css>
<!-- 10/24/2014>
<!-- saved from url=(0099)#s7.3.2-javadoc-exception-overrides -->

<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  
  <link rel="stylesheet" type="text/css" href="javaguide.css">
  <script src="https://google-code-prettify.googlecode.com/svn/loader/run_prettify.js" type="text/javascript"></script>
  <link href="http://www.google.com/favicon.ico" type="image/x-icon" rel="shortcut icon">
  <title>Google Java 风格</title>
</head>
<body>
  <h1>Google Java 风格</h1>
  <div class="change">最后修改于2014年3月21日</div>
<table border="0">
<tbody><tr>
<td>
<dl>
<br>
<dt class="toc1">
<a href="#s1-introduction">1 引言</a>
</dt>
<dd>
<a href="#s1.1-terminology">1.1 术语注解</a>
</dd>
<dd>
<a href="#s1.2-guide-notes">1.2 依据注解</a>
</dd>
<br>
<dt class="toc1">
<a href="#s2-source-file-basics">2 源文件基本部分</a>
</dt>
<dd>
<a href="#s2.1-file-name">2.1 文件名</a>
</dd>
<dd>
<a href="#s2.2-file-encoding">2.2 文件编码：UTF-8</a>
</dd>
<dd>
<a href="#s2.3-special-characters">2.3 特殊字符</a>
</dd>
<dd class="toc3">
<a href="#s2.3.1-whitespace-characters">2.3.1 空白符</a>
</dd>
<dd class="toc3">
<a href="#s2.3.2-special-escape-sequences">2.3.2 特殊的转义符</a>
</dd>
<dd class="toc3">
<a href="#s2.3.3-non-ascii-characters">2.3.3 非ASCII字符</a>
</dd>
<br>
<dt class="toc1">
<a href="#s3-source-file-structure">3 源文件结构</a>
</dt>
<dd>
<a href="#s3.1-copyright-statement">3.1 许可或版权信息，如果有</a>
</dd>
<dd>
<a href="#s3.2-package-statement">3.2 声明包</a>
</dd>
<dd>
<a href="#s3.3-import-statements">3.3 声明引入</a>
</dd>
<dd class="toc3">
<a href="#s3.3.1-wildcard-imports">3.3.1 勿使用通配符引入</a>
</dd>
<dd class="toc3">
<a href="#s3.3.2-import-line-wrapping">3.3.2 不换行</a>
</dd>
<dd class="toc3">
<a href="#s3.3.3-import-ordering-and-spacing">3.3.3 排列与间距</a>
</dd>
<dd>
<a href="#s3.4-class-declaration">3.4 声明类</a>
</dd>
<dd class="toc3">
<a href="#s3.4.1-one-top-level-class">3.4.1 唯一顶层类声明</a>
</dd>
<dd class="toc3">
<a href="#s3.4.2-class-member-ordering">3.4.2 排列类成员</a>
</dd>
</dl>
</td><td>
<dl>
<br>
<dt class="toc1">
<a href="#s4-formatting">4 格式</a>
</dt>
<dd>
<a href="#s4.1-braces">4.1 花括号</a>
</dd>
<dd class="toc3">
<a href="#s4.1.1-braces-always-used">4.1.1 何处花括号可选</a>
</dd>
<dd class="toc3">
<a href="#s4.1.2-blocks-k-r-style">4.1.2 非空块: K &amp; R 样式</a>
</dd>
<dd class="toc3">
<a href="#s4.1.3-braces-empty-blocks">4.1.3 空块: 可以很简洁</a>
</dd>
<dd>
<a href="#s4.2-block-indentation">4.2 块缩进: +2 空格</a>
</dd>
<dd>
<a href="#s4.3-one-statement-per-line">4.3 一行一语句</a>
</dd>
<dd>
<a href="#s4.4-column-limit">4.4 列数限制: 80 or 100</a>
</dd>
<dd>
<a href="#s4.5-line-wrapping">4.5 换行</a>
</dd>
<dd class="toc3">
<a href="#s4.5.1-line-wrapping-where-to-break">4.5.1 何处截断</a>
</dd>
<dd class="toc3">
<a href="#s4.5.2-line-wrapping-indent">4.5.2 缩进连续行至少 +4 空格</a>
</dd>
<dd>
<a href="#s4.6-whitespace">4.6 空白符</a>
</dd>
<dd class="toc3">
<a href="#s4.6.1-vertical-whitespace">4.6.1 垂直空白符</a>
</dd>
<dd class="toc3">
<a href="#s4.6.2-horizontal-whitespace">4.6.2 水平空白符</a>
</dd>
<dd class="toc3">
<a href="#s4.6.3-horizontal-alignment">4.6.3 水平对齐：从不要求</a>
</dd>
<dd>
<a href="#s4.7-grouping-parentheses">4.7 分组括号：推荐</a>
</dd>
<dd>
<a href="#s4.8-specific-constructs">4.8 特殊结构</a>
</dd>
<dd class="toc3">
<a href="#s4.8.1-enum-classes">4.8.1 枚举类</a>
</dd>
<dd class="toc3">
<a href="#s4.8.2-variable-declarations">4.8.2 变量声明</a>
</dd>
<dd class="toc3">
<a href="#s4.8.3-arrays">4.8.3 数组</a>
</dd>
<dd class="toc3">
<a href="#s4.8.4-switch">4.8.4 开关语句</a>
</dd>
<dd class="toc3">
<a href="#s4.8.5-annotations">4.8.5 注解</a>
</dd>
<dd class="toc3">
<a href="#s4.8.6-comments">4.8.6 注释</a>
</dd>
<dd class="toc3">
<a href="#s4.8.7-modifiers">4.8.7 修饰符</a>
</dd>
<dd class="toc3">
<a href="#s4.8.8-numeric-literals">4.8.8 数字符</a>
</dd>
</dl>
</td><td>
<dl>
<br>
<dt class="toc1">
<a href="#s5-naming">5 命名</a>
</dt>
<dd>
<a href="#s5.1-identifier-names">5.1 适用于所有标识符的规则</a>
</dd>
<dd>
<a href="#s5.2-specific-identifier-names">5.2 按标识符类型分类的规则</a>
</dd>
<dd class="toc3">
<a href="#s5.2.1-package-names">5.2.1 命名包</a>
</dd>
<dd class="toc3">
<a href="#s5.2.2-class-names">5.2.2 命名类</a>
</dd>
<dd class="toc3">
<a href="#s5.2.3-method-names">5.2.3 命名方法</a>
</dd>
<dd class="toc3">
<a href="#s5.2.4-constant-names">5.2.4 命名常量</a>
</dd>
<dd class="toc3">
<a href="#s5.2.5-non-constant-field-names">5.2.5 命名非常量字段</a>
</dd>
<dd class="toc3">
<a href="#s5.2.6-parameter-names">5.2.6 命名参数</a>
</dd>
<dd class="toc3">
<a href="#s5.2.7-local-variable-names">5.2.7 命名本地变量</a>
</dd>
<dd class="toc3">
<a href="#s5.2.8-type-variable-names">5.2.8 命名类型变量</a>
</dd>
<dd>
<a href="#s5.3-camel-case">5.3 科莫大小写： 定义</a>
</dd>
<br>
<dt class="toc1">
<a href="#s6-programming-practices">6 编码习惯</a>
</dt>
<dd>
<a href="#s6.1-override-annotation">6.1 @Override：总是采用</a>
</dd>
<dd>
<a href="#s6.2-caught-exceptions">6.2 捕捉到的异常: 别忽略</a>
</dd>
<dd>
<a href="#s6.3-static-members">6.3 静态成员: 使用类修饰</a>
</dd>
<dd>
<a href="#s6.4-finalizers">6.4 Finalizers：别用了</a>
</dd>
<br>
<dt class="toc1">
<a href="#s7-javadoc">7 Javadoc</a>
</dt>
<dd>
<a href="#s7.1-javadoc-formatting">7.1 格式</a>
</dd>
<dd class="toc3">
<a href="#s7.1.1-javadoc-multi-line">7.1.1 一般形式</a>
</dd>
<dd class="toc3">
<a href="#s7.1.2-javadoc-paragraphs">7.1.2 段落</a>
</dd>
<dd class="toc3">
<a href="#s7.1.3-javadoc-at-clauses">7.1.3 分句处</a>
</dd>
<dd>
<a href="#s7.2-summary-fragment">7.2 The summary fragment</a>
</dd>
<dd>
<a href="#s7.3-javadoc-where-required">7.3 何处用到Javadoc </a>
</dd>
<dd class="toc3">
<a href="#s7.3.1-javadoc-exception-self-explanatory">7.3.1 异常: 自我解释方法</a>
</dd>
<dd class="toc3">
<a href="Google Java Style.html">7.3.2 异常: 重载</a>
</dd>
</dl>
</td>
</tr>
</tbody></table>
<div><a name="s1-introduction">
    </a><h2><a name="s1-introduction">1 引言&nbsp;</a><a href="#s1-introduction"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <p>此文档用于<strong> 完整 </strong>定义Google的Java™程序语言源代码的编码规范。一个Java 源文件被描述为<em> 采用Google Style </em>当且仅当它遵循此处的规则。</p><p>如同其它的编码风格指导书一样，风格所涵盖的问题不仅有排版上的审美争议，还有其它类型的约定或编码规范争议，然而本文主要关注那些我们常用的<strong> 不易变的规则 </strong>，并且避免给出可行性(无论是通过人或工具实现)不甚明了的<em> 建议 </em>。
</p><a name="s1.1-terminology">
    </a><h3><a name="s1.1-terminology">1.1 术语注释&nbsp;</a><a href="#s1.1-terminology"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>本文档中, 除非另行说明:</p><ol><li>术语<em> class </em>被统一地用于表达 “通常” 类，枚举类，
接口或注解类型	(<code class="prettyprint lang-java">@interface</code>)。</li><li>术语<em> comment </em>总是指的是<em> 实施 </em>的注释。 我们不使用“文档注释”这个短语，而采用通常术语“Javadoc”。</li></ol><p>在贯穿全文的过程中，其它术语注解会偶尔出现。</p><a name="s1.2-guide-notes">
    </a><h3><a name="s1.2-guide-notes">1.2 依据注解&nbsp;</a><a href="#s1.2-guide-notes"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>本文档中的示例代码是<strong> 非标准的 </strong>。 就是说，虽然这些例子是采用Google Style，但它们并没有说明描述代码<em> 唯一 </em>的风格化方法，示例中作出的可选格式选择不应该强制作为规则。</p><a name="s2-source-file-basics">
    </a><h2><a name="s2-source-file-basics">2 源文件基本部分&nbsp;</a><a href="#s2-source-file-basics"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <a name="s2.1-file-name">
    </a><h3><a name="s2.1-file-name">2.1 文件名&nbsp;</a><a href="#s2.1-file-name"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>源文件名由文件中的顶层类的名称（大小写敏感）加上<code>.java</code>扩展名构成。</p><a name="s2.2-file-encoding">
    </a><h3><a name="s2.2-file-encoding">2.2 文件编码: UTF-8&nbsp;</a><a href="#s2.2-file-encoding"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>源文件编码采用<strong> UTF-8 </strong>。</p><a name="s2.3-special-characters">
    </a><h3><a name="s2.3-special-characters">2.3 特殊字符集&nbsp;</a><a href="#s2.3-special-characters"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s2.3.1-whitespace-characters">
    </a><h4><a name="s2.3.1-whitespace-characters">2.3.1 空白符集&nbsp;</a><a href="#s2.3.1-whitespace-characters"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>除了行结束序列外，<strong> ASCII水平空白符 </strong> (<strong>0x20</strong>)是唯一会出现在源文件内的空白符，这意味着</p><ol><li>其它所有字符串内的空白符和Character literals均被转义。</li><li>制表符<strong> 不 </strong>用于缩进。</li></ol><a name="s2.3.2-special-escape-sequences">
    </a><h4><a name="s2.3.2-special-escape-sequences">2.3.2	特殊的转义序列&nbsp;</a><a href="#s2.3.2-special-escape-sequences"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>对于任何有着一个特殊转义序列的字符来说，
(<code class="prettyprint lang-java">\b</code>,
<code class="prettyprint lang-java">\t</code>,
<code class="prettyprint lang-java">\n</code>,
<code class="prettyprint lang-java">\f</code>,
<code class="prettyprint lang-java">\r</code>,
<code class="prettyprint lang-java">\"</code>,
<code class="prettyprint lang-java">\'</code> 和
<code class="prettyprint lang-java">\\</code>), 这个转义序列被使用而非其八进制(比如&nbsp;<code class="badcode">\012</code>) 或者 Unicode
(比如&nbsp;<code class="badcode">\u000a</code>)转义。</p><a name="s2.3.3-non-ascii-characters">
    </a><h4><a name="s2.3.3-non-ascii-characters">2.3.3 非-ASCII字符&nbsp;</a><a href="#s2.3.3-non-ascii-characters"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>对于剩下的非-ASCII字符，要么使用实际的Unicode字符
(比如&nbsp;<code class="prettyprint lang-java">∞</code>) 要么使用相等的Unicode转义
(比如&nbsp;<code class="prettyprint lang-java">\u221e</code>)，仅取决于哪种会使代码更加<strong> 简单易于理解 </strong>.</p><p class="tip"><strong>提示:</strong>在Unicode转义例子中，有时即便使用了实际的Unicode字符，一个解释性的评论也可以很有帮助。</p><p>示例:</p><table><tbody><tr><th>示例</th><th>讨论</th></tr><tr><td><code class="prettyprint lang-java">String unitAbbrev = "μs";</code></td><td>最好: 即便没有注释代码也十分清晰。</td></tr><tr><td><code class="prettyprint lang-java">String unitAbbrev = "\u03bcs"; // "μs"</code></td><td>允许，不过搞不懂为什么这么做。</td></tr><tr><td><code class="prettyprint lang-java">String unitAbbrev = "\u03bcs";
      // Greek letter mu, "s"</code></td><td>允许，但很拙而且容易出错。</td></tr><tr><td><code class="badcode">String unitAbbrev = "\u03bcs";</code></td><td>很差: 读者根本不知道它是什么</td></tr><tr><td><code class="prettyprint lang-java">return '\ufeff' + content;
       // byte order mark</code></td><td>很好: 使用转义字符来表示不可见字符，有需要的话加上评论。</td></tr></tbody></table><p class="tip"><strong>提示:</strong>千万不要因为害怕有些程序不能正常处理非-ASCII字符集，就放任不管代码的可读性，如果它真的发生，只能说明这些程序<strong> 有毛病 </strong>必须要<strong> 维护 </strong>了。</p><a name="filestructure"></a><a name="s3-source-file-structure">
    </a><h2><a name="s3-source-file-structure">3 Source file structure&nbsp;</a><a href="#s3-source-file-structure"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <div><p>A source file consists of, <strong>in order</strong>:</p><ol><li>License or copyright information, if present</li><li>Package statement</li><li>Import statements</li><li>Exactly one top-level class</li></ol></div><p><strong>Exactly one blank line</strong> separates each section that is present.</p><a name="s3.1-copyright-statement">
    </a><h3><a name="s3.1-copyright-statement">3.1 License or copyright information, if present&nbsp;</a><a href="#s3.1-copyright-statement"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>If license or copyright information belongs in a file, it belongs here.</p><a name="s3.2-package-statement">
    </a><h3><a name="s3.2-package-statement">3.2 Package statement&nbsp;</a><a href="#s3.2-package-statement"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>The package statement is <strong>not line-wrapped</strong>. The column limit (Section 4.4,
<a href="#s4.4-column-limit">Column limit: 80 or 100</a>) does not apply to package statements.</p><a name="imports"></a><a name="s3.3-import-statements">
    </a><h3><a name="s3.3-import-statements">3.3 Import statements&nbsp;</a><a href="#s3.3-import-statements"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s3.3.1-wildcard-imports">
    </a><h4><a name="s3.3.1-wildcard-imports">3.3.1 No wildcard imports&nbsp;</a><a href="#s3.3.1-wildcard-imports"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p><strong>Wildcard imports</strong>, static or otherwise, <strong>are not used</strong>.</p><a name="s3.3.2-import-line-wrapping">
    </a><h4><a name="s3.3.2-import-line-wrapping">3.3.2 No line-wrapping&nbsp;</a><a href="#s3.3.2-import-line-wrapping"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Import statements are <strong>not line-wrapped</strong>. The column limit (Section 4.4,
<a href="#s4.4-column-limit">Column limit: 80 or 100</a>) does not apply to import
statements.</p><a name="s3.3.3-import-ordering-and-spacing">
    </a><h4><a name="s3.3.3-import-ordering-and-spacing">3.3.3 Ordering and spacing&nbsp;</a><a href="#s3.3.3-import-ordering-and-spacing"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Import statements are divided into the following groups, in this order, with each group
separated by a single blank line:</p><ol><li>All static imports in a single group</li><li><code>com.google</code> imports
  (only if this source file is in the <code>com.google</code> package
  space)</li><li>Third-party imports, one group per top-level package, in ASCII sort order
  <ul><li>for example: <code>android</code>, <code>com</code>, <code>junit</code>, <code>org</code>,
    <code>sun</code></li></ul></li><li><code>java</code> imports</li><li><code>javax</code> imports</li></ol><p>Within a group there are no blank lines, and the imported names appear in ASCII sort
order. (<strong>Note:</strong> this is not the same as the import <em>statements</em> being in
ASCII sort order; the presence of semicolons warps the result.)</p><a name="s3.4-class-declaration">
    </a><h3><a name="s3.4-class-declaration">3.4 Class declaration&nbsp;</a><a href="#s3.4-class-declaration"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="oneclassperfile"></a><a name="s3.4.1-one-top-level-class">
    </a><h4><a name="s3.4.1-one-top-level-class">3.4.1 Exactly one top-level class declaration&nbsp;</a><a href="#s3.4.1-one-top-level-class"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Each top-level class resides in a source file of its own.</p><a name="s3.4.2-class-member-ordering">
    </a><h4><a name="s3.4.2-class-member-ordering">3.4.2 Class member ordering&nbsp;</a><a href="#s3.4.2-class-member-ordering"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>The ordering of the members of a class can have a great effect on learnability, but there is
no single correct recipe for how to do it. Different classes may order their members
differently.</p><p>What is important is that each class order its members in <strong><em>some</em> logical
order</strong>, which its maintainer could explain if asked. For example, new methods are not
just habitually added to the end of the class, as that would yield "chronological by date
added" ordering, which is not a logical ordering.</p><a name="overloads"></a><a name="s3.4.2.1-overloads-never-split">
    </a><h5><a name="s3.4.2.1-overloads-never-split">3.4.2.1 Overloads: never split&nbsp;</a><a href="#s3.4.2.1-overloads-never-split"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>When a class has multiple constructors, or multiple methods with the same name, these appear
sequentially, with no intervening members.</p><a name="s4-formatting">
    </a><h2><a name="s4-formatting">4 Formatting&nbsp;</a><a href="#s4-formatting"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <p class="terminology"><strong>Terminology Note:</strong> <em>block-like construct</em> refers to
the body of a class, method or constructor. Note that, by Section 4.8.3.1 on
<a href="#s4.8.3.1-array-initializers">array initializers</a>, any array initializer
<em>may</em> optionally be treated as if it were a block-like construct.</p><a name="braces"></a><a name="s4.1-braces">
    </a><h3><a name="s4.1-braces">4.1 Braces&nbsp;</a><a href="#s4.1-braces"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s4.1.1-braces-always-used">
    </a><h4><a name="s4.1.1-braces-always-used">4.1.1 Braces are used where optional&nbsp;</a><a href="#s4.1.1-braces-always-used"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Braces are used with
<code class="prettyprint lang-java">if</code>,
<code class="prettyprint lang-java">else</code>,
<code class="prettyprint lang-java">for</code>,
<code class="prettyprint lang-java">do</code> and
<code class="prettyprint lang-java">while</code> statements, even when the
body is empty or contains only a single statement.</p><a name="s4.1.2-blocks-k-r-style">
    </a><h4><a name="s4.1.2-blocks-k-r-style">4.1.2 Nonempty blocks: K &amp; R style&nbsp;</a><a href="#s4.1.2-blocks-k-r-style"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Braces follow the Kernighan and Ritchie style
("<a href="http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html">Egyptian brackets</a>")
for <em>nonempty</em> blocks and block-like constructs:</p><ul><li>No line break before the opening brace.</li><li>Line break after the opening brace.</li><li>Line break before the closing brace.</li><li>Line break after the closing brace <em>if</em> that brace terminates a statement or the body
  of a method, constructor or <em>named</em> class. For example, there is <em>no</em> line break
  after the brace if it is followed by <code class="prettyprint lang-java">else</code> or a
  comma.</li></ul><p>Example:</p><pre class="prettyprint lang-java">return new MyClass() {
  @Override public void method() {
    if (condition()) {
      try {
        something();
      } catch (ProblemException e) {
        recover();
      }
    }
  }
};
</pre><p>A few exceptions for enum classes are given in Section 4.8.1,
<a href="#s4.8.1-enum-classes">Enum classes</a>.</p><a name="emptyblocks"></a><a name="s4.1.3-braces-empty-blocks">
    </a><h4><a name="s4.1.3-braces-empty-blocks">4.1.3 Empty blocks: may be concise&nbsp;</a><a href="#s4.1.3-braces-empty-blocks"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>An empty block or block-like construct <em>may</em> be closed immediately after it is
opened, with no characters or line break in between
(<code class="prettyprint lang-java">{}</code>), <strong>unless</strong> it is part of a
<em>multi-block statement</em> (one that directly contains multiple blocks:
<code class="prettyprint lang-java">if/else-if/else</code> or
<code class="prettyprint lang-java">try/catch/finally</code>).</p><p>Example:</p><pre class="prettyprint lang-java">  void doNothing() {}
</pre><a name="s4.2-block-indentation">
    </a><h3><a name="s4.2-block-indentation">4.2 Block indentation: +2 spaces&nbsp;</a><a href="#s4.2-block-indentation"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Each time a new block or block-like construct is opened, the indent increases by two
spaces. When the block ends, the indent returns to the previous indent level. The indent level
applies to both code and comments throughout the block. (See the example in Section 4.1.2,
<a href="#s4.1.2-blocks-k-r-style">Nonempty blocks: K &amp; R Style</a>.)</p><a name="s4.3-one-statement-per-line">
    </a><h3><a name="s4.3-one-statement-per-line">4.3 One statement per line&nbsp;</a><a href="#s4.3-one-statement-per-line"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Each statement is followed by a line-break.</p><a name="columnlimit"></a><a name="s4.4-column-limit">
    </a><h3><a name="s4.4-column-limit">4.4 Column limit: 80 or 100&nbsp;</a><a href="#s4.4-column-limit"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>
  Projects are free to choose a column limit of either 80 or 100 characters.

Except as noted below, any line that would exceed this limit must be line-wrapped, as explained in
Section 4.5, <a href="#s4.5-line-wrapping">Line-wrapping</a>.
</p><p><strong>Exceptions:</strong></p><ol><li>Lines where obeying the column limit is not possible (for example, a long URL in Javadoc,
  or a long JSNI method reference).</li><li><code class="prettyprint lang-java">package</code> and
  <code class="prettyprint lang-java">import</code> statements (see Sections
  3.2 <a href="#s3.2-package-statement">Package statement</a> and
  3.3 <a href="#s3.3-import-statements">Import statements</a>).</li><li>Command lines in a comment that may be cut-and-pasted into a shell.</li></ol><a name="s4.5-line-wrapping">
    </a><h3><a name="s4.5-line-wrapping">4.5 Line-wrapping&nbsp;</a><a href="#s4.5-line-wrapping"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p class="terminology"><strong>Terminology Note:</strong> When code that might otherwise legally
occupy a single line is divided into multiple lines, typically to avoid overflowing the column
limit, this activity is called
<em>line-wrapping</em>.</p><p>There is no comprehensive, deterministic formula showing <em>exactly</em> how to line-wrap in
every situation. Very often there are several valid ways to line-wrap the same piece of code.</p><p class="tip"><strong>Tip:</strong> Extracting a method or local variable may solve the problem
without the need to line-wrap.</p><a name="s4.5.1-line-wrapping-where-to-break">
    </a><h4><a name="s4.5.1-line-wrapping-where-to-break">4.5.1 Where to break&nbsp;</a><a href="#s4.5.1-line-wrapping-where-to-break"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>The prime directive of line-wrapping is: prefer to break at a
<strong>higher syntactic level</strong>. Also:</p><ol><li>When a line is broken at a <em>non-assignment</em> operator the break comes <em>before</em>
  the symbol. (Note that this is not the same practice used in Google style for other languages,
  such as C++ and JavaScript.)
    <ul><li>This also applies to the following "operator-like" symbols: the dot separator
      (<code class="prettyprint lang-java">.</code>), the ampersand in type bounds
      (<code class="prettyprint lang-java">&lt;T extends Foo &amp; Bar&gt;</code>), and the pipe in
      catch blocks
      (<code class="prettyprint lang-java">catch (FooException | BarException e)</code>).</li></ul></li><li>When a line is broken at an <em>assignment</em> operator the break typically comes
  <em>after</em> the symbol, but either way is acceptable.
    <ul><li>This also applies to the "assignment-operator-like" colon in an enhanced
      <code class="prettyprint lang-java">for</code> ("foreach") statement.</li></ul></li><li>A method or constructor name stays attached to the open parenthesis
  (<code class="prettyprint lang-java">(</code>) that follows it.</li><li>A comma (<code class="prettyprint lang-java">,</code>) stays attached to the token that
  precedes it.</li></ol><a name="indentation"></a><a name="s4.5.2-line-wrapping-indent">
    </a><h4><a name="s4.5.2-line-wrapping-indent">4.5.2 Indent continuation lines at least +4 spaces&nbsp;</a><a href="#s4.5.2-line-wrapping-indent"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>When line-wrapping, each line after the first (each <em>continuation line</em>) is indented
at least +4 from the original line.</p><p>When there are multiple continuation lines, indentation may be varied beyond +4 as
desired. In general, two continuation lines use the same indentation level if and only if they
begin with syntactically parallel elements.</p><p>Section 4.6.3 on <a href="#s4.6.3-horizontal-alignment">Horizontal alignment</a> addresses
the discouraged practice of using a variable number of spaces to align certain tokens with
previous lines.</p><a name="s4.6-whitespace">
    </a><h3><a name="s4.6-whitespace">4.6 Whitespace&nbsp;</a><a href="#s4.6-whitespace"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s4.6.1-vertical-whitespace">
    </a><h4><a name="s4.6.1-vertical-whitespace">4.6.1 Vertical Whitespace&nbsp;</a><a href="#s4.6.1-vertical-whitespace"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>A single blank line appears:</p><ol><li><em>Between</em> consecutive members (or initializers) of a class: fields, constructors,
  methods, nested classes, static initializers, instance initializers.
  <ul><li><span class="exception"><strong>Exception:</strong> A blank line between two consecutive
    fields (having no other code between them) is optional. Such blank lines are used as needed to
    create <em>logical groupings</em> of fields.</span></li></ul></li><li>Within method bodies, as needed to create <em>logical groupings</em> of statements.</li><li><em>Optionally</em> before the first member or after the last member of the class (neither
  encouraged nor discouraged).</li><li>As required by other sections of this document (such as Section 3.3,
  <a href="#s3.3-import-statements">Import statements</a>).</li></ol><p><em>Multiple</em> consecutive blank lines are permitted, but never required (or encouraged).</p><a name="s4.6.2-horizontal-whitespace">
    </a><h4><a name="s4.6.2-horizontal-whitespace">4.6.2 Horizontal whitespace&nbsp;</a><a href="#s4.6.2-horizontal-whitespace"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Beyond where required by the language or other style rules, and apart from literals, comments and
Javadoc, a single ASCII space also appears in the following places <strong>only</strong>.</p><ol><li>Separating any reserved word, such as
  <code class="prettyprint lang-java">if</code>,
  <code class="prettyprint lang-java">for</code> or
  <code class="prettyprint lang-java">catch</code>, from an open parenthesis
  (<code class="prettyprint lang-java">(</code>)
  that follows it on that line</li><li>Separating any reserved word, such as
  <code class="prettyprint lang-java">else</code> or
  <code class="prettyprint lang-java">catch</code>, from a closing curly brace
  (<code class="prettyprint lang-java">}</code>) that precedes it on that line</li><li>Before any open curly brace
  (<code class="prettyprint lang-java">{</code>), with two exceptions:
  <ul><li><code class="prettyprint lang-java">@SomeAnnotation({a, b})</code> (no space is used)</li><li><code class="prettyprint lang-java">String[][] x = {{"foo"}};</code> (no space is required
    between <code class="prettyprint lang-java">{{</code>, by item 8 below)</li></ul></li><li>On both sides of any binary or ternary operator. This also applies to the following
  "operator-like" symbols:
  <ul><li>the ampersand in a conjunctive type bound:
    <code class="prettyprint lang-java">&lt;T extends Foo &amp; Bar&gt;</code></li><li>the pipe for a catch block that handles multiple exceptions:
    <code class="prettyprint lang-java">catch (FooException | BarException e)</code></li><li>the colon (<code class="prettyprint lang-java">:</code>) in an enhanced
    <code class="prettyprint lang-java">for</code> ("foreach") statement</li></ul></li><li>After <code class="prettyprint lang-java">,:;</code> or the closing parenthesis
  (<code class="prettyprint lang-java">)</code>) of a cast</li><li>On both sides of the double slash (<code class="prettyprint lang-java">//</code>) that
  begins an end-of-line comment. Here, multiple spaces are allowed, but not required.</li><li>Between the type and variable of a declaration:
  <code class="prettyprint lang-java">List&lt;String&gt; list</code></li><li><em>Optional</em> just inside both braces of an array initializer
  <ul><li><code class="prettyprint lang-java">new int[] {5, 6}</code> and
    <code class="prettyprint lang-java">new int[] { 5, 6 }</code> are both valid</li></ul></li></ol><p class="note"><strong>Note:</strong> This rule never requires or forbids additional space at the
start or end of a line, only <em>interior</em> space.</p><a name="s4.6.3-horizontal-alignment">
    </a><h4><a name="s4.6.3-horizontal-alignment">4.6.3 Horizontal alignment: never required&nbsp;</a><a href="#s4.6.3-horizontal-alignment"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p class="terminology"><strong>Terminology Note:</strong> <em>Horizontal alignment</em> is the
practice of adding a variable number of additional spaces in your code with the goal of making
certain tokens appear directly below certain other tokens on previous lines.</p><p>This practice is permitted, but is <strong>never required</strong> by Google Style. It is not
even required to <em>maintain</em> horizontal alignment in places where it was already used.</p><p>Here is an example without alignment, then using alignment:</p><pre class="prettyprint lang-java">private int x; // this is fine
private Color color; // this too

private int   x;      // permitted, but future edits
private Color color;  // may leave it unaligned
</pre><p class="tip"><strong>Tip:</strong> Alignment can aid readability, but it creates problems for
future maintenance.  Consider a future change that needs to touch just one line. This change may
leave the formerly-pleasing formatting mangled, and that is <strong>allowed</strong>. More often
it prompts the coder (perhaps you) to adjust whitespace on nearby lines as well, possibly
triggering a cascading series of reformattings. That one-line change now has a "blast radius."
This can at worst result in pointless busywork, but at best it still corrupts version history
information, slows down reviewers and exacerbates merge conflicts.</p><a name="parentheses"></a><a name="s4.7-grouping-parentheses">
    </a><h3><a name="s4.7-grouping-parentheses">4.7 Grouping parentheses: recommended&nbsp;</a><a href="#s4.7-grouping-parentheses"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Optional grouping parentheses are omitted only when author and reviewer agree that there is no
reasonable chance the code will be misinterpreted without them, nor would they have made the code
easier to read. It is <em>not</em> reasonable to assume that every reader has the entire Java
operator precedence table memorized.</p><a name="s4.8-specific-constructs">
    </a><h3><a name="s4.8-specific-constructs">4.8 Specific constructs&nbsp;</a><a href="#s4.8-specific-constructs"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s4.8.1-enum-classes">
    </a><h4><a name="s4.8.1-enum-classes">4.8.1 Enum classes&nbsp;</a><a href="#s4.8.1-enum-classes"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>After each comma that follows an enum constant, a line-break is optional.</p><p>An enum class with no methods and no documentation on its constants may optionally be formatted
as if it were an array initializer (see Section 4.8.3.1 on
<a href="#s4.8.3.1-array-initializers">array initializers</a>).</p><pre class="prettyprint lang-java">private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }
</pre><p>Since enum classes <em>are classes</em>, all other rules for formatting classes apply.</p><a name="localvariables"></a><a name="s4.8.2-variable-declarations">
    </a><h4><a name="s4.8.2-variable-declarations">4.8.2 Variable declarations&nbsp;</a><a href="#s4.8.2-variable-declarations"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <a name="s4.8.2.1-variables-per-declaration">
    </a><h5><a name="s4.8.2.1-variables-per-declaration">4.8.2.1 One variable per declaration&nbsp;</a><a href="#s4.8.2.1-variables-per-declaration"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Every variable declaration (field or local) declares only one variable: declarations such as
<code class="badcode">int a, b;</code> are not used.</p><a name="s4.8.2.2-variables-limited-scope">
    </a><h5><a name="s4.8.2.2-variables-limited-scope">4.8.2.2 Declared when needed, initialized as soon as
possible&nbsp;</a><a href="#s4.8.2.2-variables-limited-scope"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Local variables are <strong>not</strong> habitually declared at the start of their containing
block or block-like construct. Instead, local variables are declared close to the point they are
first used (within reason), to minimize their scope. Local variable declarations typically have
initializers, or are initialized immediately after declaration.</p><a name="s4.8.3-arrays">
    </a><h4><a name="s4.8.3-arrays">4.8.3 Arrays&nbsp;</a><a href="#s4.8.3-arrays"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <a name="s4.8.3.1-array-initializers">
    </a><h5><a name="s4.8.3.1-array-initializers">4.8.3.1 Array initializers: can be "block-like"&nbsp;</a><a href="#s4.8.3.1-array-initializers"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Any array initializer may <em>optionally</em> be formatted as if it were a "block-like
construct." For example, the following are all valid (<strong>not</strong> an exhaustive
list):</p><pre class="prettyprint lang-java">new int[] {           new int[] {
  0, 1, 2, 3            0,
}                       1,
                        2,
new int[] {             3,
  0, 1,               }
  2, 3
}                     new int[]
                          {0, 1, 2, 3}
</pre><a name="s4.8.3.2-array-declarations">
    </a><h5><a name="s4.8.3.2-array-declarations">4.8.3.2 No C-style array declarations&nbsp;</a><a href="#s4.8.3.2-array-declarations"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>The square brackets form a part of the <em>type</em>, not the variable:
<code class="prettyprint lang-java">String[] args</code>, not
<code class="badcode">String args[]</code>.</p><a name="s4.8.4-switch">
    </a><h4><a name="s4.8.4-switch">4.8.4 Switch statements&nbsp;</a><a href="#s4.8.4-switch"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p class="terminology"><strong>Terminology Note:</strong> Inside the braces of a
<em>switch block</em> are one or more <em>statement groups</em>. Each statement group consists of
one or more <em>switch labels</em> (either <code class="prettyprint lang-java">case FOO:</code> or
<code class="prettyprint lang-java">default:</code>), followed by one or more statements.</p><a name="s4.8.4.1-switch-indentation">
    </a><h5><a name="s4.8.4.1-switch-indentation">4.8.4.1 Indentation&nbsp;</a><a href="#s4.8.4.1-switch-indentation"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>As with any other block, the contents of a switch block are indented +2.</p><p>After a switch label, a newline appears, and the indentation level is increased +2, exactly as
if a block were being opened. The following switch label returns to the previous indentation
level, as if a block had been closed.</p><a name="fallthrough"></a><a name="s4.8.4.2-switch-fall-through">
    </a><h5><a name="s4.8.4.2-switch-fall-through">4.8.4.2 Fall-through: commented&nbsp;</a><a href="#s4.8.4.2-switch-fall-through"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Within a switch block, each statement group either terminates abruptly (with a
<code class="prettyprint lang-java">break</code>,
<code class="prettyprint lang-java">continue</code>,
<code class="prettyprint lang-java">return</code> or thrown exception), or is marked with a comment
to indicate that execution will or <em>might</em> continue into the next statement group. Any
comment that communicates the idea of fall-through is sufficient (typically
<code class="prettyprint lang-java">// fall through</code>). This special comment is not required in
the last statement group of the switch block. Example:</p><pre class="prettyprint lang-java">switch (input) {
  case 1:
  case 2:
    prepareOneOrTwo();
    // fall through
  case 3:
    handleOneTwoOrThree();
    break;
  default:
    handleLargeNumber(input);
}
</pre><a name="s4.8.4.3-switch-default">
    </a><h5><a name="s4.8.4.3-switch-default">4.8.4.3 The default case is present&nbsp;</a><a href="#s4.8.4.3-switch-default"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Each switch statement includes a <code class="prettyprint lang-java">default</code> statement
group, even if it contains no code.</p><a name="annotations"></a><a name="s4.8.5-annotations">
    </a><h4><a name="s4.8.5-annotations">4.8.5 Annotations&nbsp;</a><a href="#s4.8.5-annotations"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Annotations applying to a class, method or constructor appear immediately after the
documentation block, and each annotation is listed on a line of its own (that is, one annotation
per line). These line breaks do not constitute line-wrapping (Section
4.5, <a href="#s4.5-line-wrapping">Line-wrapping</a>), so the indentation level is not
increased. Example:</p><pre class="prettyprint lang-java">@Override
@Nullable
public String getNameIfPresent() { ... }
</pre><p class="exception"><strong>Exception:</strong> A <em>single</em> parameterless annotation
<em>may</em> instead appear together with the first line of the signature, for example:</p><pre class="prettyprint lang-java">@Override public int hashCode() { ... }
</pre><p>Annotations applying to a field also appear immediately after the documentation block, but in
this case, <em>multiple</em> annotations (possibly parameterized) may be listed on the same line;
for example:</p><pre class="prettyprint lang-java">@Partial @Mock DataLoader loader;
</pre><p>There are no specific rules for formatting parameter and local variable annotations.</p><a name="comments"></a><a name="s4.8.6-comments">
    </a><h4><a name="s4.8.6-comments">4.8.6 Comments&nbsp;</a><a href="#s4.8.6-comments"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <a name="s4.8.6.1-block-comment-style">
    </a><h5><a name="s4.8.6.1-block-comment-style">4.8.6.1 Block comment style&nbsp;</a><a href="#s4.8.6.1-block-comment-style"><img height="21" width="21" src="javaguidelink.png"></a></h5>
    <p>Block comments are indented at the same level as the surrounding code. They may be in
<code class="prettyprint lang-java">/* ... */</code> style or
<code class="prettyprint lang-java">// ...</code> style. For multi-line
<code class="prettyprint lang-java">/* ... */</code> comments, subsequent lines must start with
<code>*</code> aligned with the <code>*</code> on the previous line.</p><pre class="prettyprint lang-java">/*
 * This is          // And so           /* Or you can
 * okay.            // is this.          * even do this. */
 */
</pre><p>Comments are not enclosed in boxes drawn with asterisks or other characters.</p><p class="tip"><strong>Tip:</strong> When writing multi-line comments, use the
<code class="prettyprint lang-java">/* ... */</code> style if you want automatic code formatters to
re-wrap the lines when necessary (paragraph-style). Most formatters don't re-wrap lines in
<code class="prettyprint lang-java">// ...</code> style comment blocks.</p><a name="modifiers"></a><a name="s4.8.7-modifiers">
    </a><h4><a name="s4.8.7-modifiers">4.8.7 Modifiers&nbsp;</a><a href="#s4.8.7-modifiers"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Class and member modifiers, when present, appear in the order
recommended by the Java Language Specification:
</p><pre>public protected private abstract static final transient volatile synchronized native strictfp
</pre><a name="s4.8.8-numeric-literals">
    </a><h4><a name="s4.8.8-numeric-literals">4.8.8 Numeric Literals&nbsp;</a><a href="#s4.8.8-numeric-literals"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p><code>long</code>-valued integer literals use an uppercase <code>L</code> suffix, never
lowercase (to avoid confusion with the digit <code>1</code>). For example, <code>3000000000L</code>
rather than <code class="badcode">3000000000l</code>.</p><a name="naming"></a><a name="s5-naming">
    </a><h2><a name="s5-naming">5 Naming&nbsp;</a><a href="#s5-naming"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <a name="s5.1-identifier-names">
    </a><h3><a name="s5.1-identifier-names">5.1 Rules common to all identifiers&nbsp;</a><a href="#s5.1-identifier-names"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Identifiers use only ASCII letters and digits, and in two cases noted below, underscores. Thus
each valid identifier name is matched by the regular expression <code>\w+</code> .</p><p> In Google Style special prefixes or
suffixes, like those seen in the examples <code class="badcode">name_</code>,
<code class="badcode">mName</code>, <code class="badcode">s_name</code> and
<code class="badcode">kName</code>, are <strong>not</strong> used.</p><a name="s5.2-specific-identifier-names">
    </a><h3><a name="s5.2-specific-identifier-names">5.2 Rules by identifier type&nbsp;</a><a href="#s5.2-specific-identifier-names"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s5.2.1-package-names">
    </a><h4><a name="s5.2.1-package-names">5.2.1 Package names&nbsp;</a><a href="#s5.2.1-package-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Package names are all lowercase, with consecutive words simply concatenated together (no
underscores). For example, <code>com.example.deepspace</code>, not
<code class="badcode">com.example.deepSpace</code> or
<code class="badcode">com.example.deep_space</code>.</p><a name="s5.2.2-class-names">
    </a><h4><a name="s5.2.2-class-names">5.2.2 Class names&nbsp;</a><a href="#s5.2.2-class-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Class names are written in <a href="#s5.3-camel-case">UpperCamelCase</a>.</p><p>Class names are typically nouns or noun phrases. For example,
<code class="prettyprint lang-java">Character</code> or
<code class="prettyprint lang-java">ImmutableList</code>. Interface names may also be nouns or
noun phrases (for example, <code class="prettyprint lang-java">List</code>), but may sometimes be
adjectives or adjective phrases instead (for example,
<code class="prettyprint lang-java">Readable</code>).</p><p>There are no specific rules or even well-established conventions for naming annotation types.</p><p><em>Test</em> classes are named starting with the name of the class they are testing, and ending
with <code class="prettyprint lang-java">Test</code>. For example,
<code class="prettyprint lang-java">HashTest</code> or
<code class="prettyprint lang-java">HashIntegrationTest</code>.</p><a name="s5.2.3-method-names">
    </a><h4><a name="s5.2.3-method-names">5.2.3 Method names&nbsp;</a><a href="#s5.2.3-method-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Method names are written in <a href="#s5.3-camel-case">lowerCamelCase</a>.</p><p>Method names are typically verbs or verb phrases. For example,
<code class="prettyprint lang-java">sendMessage</code> or
<code class="prettyprint lang-java">stop</code>.</p><p>Underscores may appear in JUnit <em>test</em> method names to separate logical components of the
name. One typical pattern is <code>test<i>&lt;MethodUnderTest&gt;</i>_<i>&lt;state&gt;</i></code>,
for example <code class="prettyprint lang-java">testPop_emptyStack</code>. There is no One Correct
Way to name test methods.</p><a name="constants"></a><a name="s5.2.4-constant-names">
    </a><h4><a name="s5.2.4-constant-names">5.2.4 Constant names&nbsp;</a><a href="#s5.2.4-constant-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Constant names use <code class="prettyprint lang-java">CONSTANT_CASE</code>: all uppercase
letters, with words separated by underscores. But what <em>is</em> a constant, exactly?</p><p>Every constant is a static final field, but not all static final fields are constants. Before
choosing constant case, consider whether the field really <em>feels like</em> a constant. For
example, if any of that instance's observable state can change, it is almost certainly not a
constant. Merely <em>intending</em> to never mutate the object is generally not
enough. Examples:</p><pre class="prettyprint lang-java">// Constants
static final int NUMBER = 5;
static final ImmutableList&lt;String&gt; NAMES = ImmutableList.of("Ed", "Ann");
static final Joiner COMMA_JOINER = Joiner.on(',');  // because Joiner is immutable
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }

// Not constants
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final Set&lt;String&gt; mutableCollection = new HashSet&lt;String&gt;();
static final ImmutableSet&lt;SomeMutableType&gt; mutableElements = ImmutableSet.of(mutable);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};
</pre><p>These names are typically nouns or noun phrases.</p><a name="s5.2.5-non-constant-field-names">
    </a><h4><a name="s5.2.5-non-constant-field-names">5.2.5 Non-constant field names&nbsp;</a><a href="#s5.2.5-non-constant-field-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Non-constant field names (static or otherwise) are written
in <a href="#s5.3-camel-case">lowerCamelCase</a>.</p><p>These names are typically nouns or noun phrases.  For example,
<code class="prettyprint lang-java">computedValues</code> or
<code class="prettyprint lang-java">index</code>.</p><a name="s5.2.6-parameter-names">
    </a><h4><a name="s5.2.6-parameter-names">5.2.6 Parameter names&nbsp;</a><a href="#s5.2.6-parameter-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Parameter names are written in <a href="#s5.3-camel-case">lowerCamelCase</a>.</p><p>One-character parameter names should be avoided.</p><a name="s5.2.7-local-variable-names">
    </a><h4><a name="s5.2.7-local-variable-names">5.2.7 Local variable names&nbsp;</a><a href="#s5.2.7-local-variable-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Local variable names are written in <a href="#s5.3-camel-case">lowerCamelCase</a>, and can be
abbreviated more liberally than other types of names.</p><p>However, one-character names should be avoided, except for temporary and looping variables.</p><p>Even when final and immutable, local variables are not considered to be constants, and should not
be styled as constants.</p><a name="s5.2.8-type-variable-names">
    </a><h4><a name="s5.2.8-type-variable-names">5.2.8 Type variable names&nbsp;</a><a href="#s5.2.8-type-variable-names"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Each type variable is named in one of two styles:</p><ul><li>A single capital letter, optionally followed by a single numeral (such as
  <code class="prettyprint lang-java">E</code>, <code class="prettyprint lang-java">T</code>,
  <code class="prettyprint lang-java">X</code>, <code class="prettyprint lang-java">T2</code>)
  </li><li>A name in the form used for classes (see Section 5.2.2,
  <a href="#s5.2.2-class-names">Class names</a>), followed by the capital letter
  <code class="prettyprint lang-java">T</code> (examples:
  <code class="prettyprint lang-java">RequestT</code>,
  <code class="prettyprint lang-java">FooBarT</code>).</li></ul><a name="acronyms"></a><a name="camelcase"></a><a name="s5.3-camel-case">
    </a><h3><a name="s5.3-camel-case">5.3 Camel case: defined&nbsp;</a><a href="#s5.3-camel-case"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Sometimes there is more than one reasonable way to convert an English phrase into camel case,
such as when acronyms or unusual constructs like "IPv6" or "iOS" are present. To improve
predictability, Google Style specifies the following (nearly) deterministic scheme.</p><p>Beginning with the prose form of the name:</p><ol><li>Convert the phrase to plain ASCII and remove any apostrophes. For example, "Müller's
  algorithm" might become "Muellers algorithm".</li><li>Divide this result into words, splitting on spaces and any remaining punctuation (typically
  hyphens).

  <ul><li><em>Recommended:</em> if any word already has a conventional camel-case appearance in common
    usage, split this into its constituent parts (e.g., "AdWords" becomes "ad&nbsp;words"). Note
    that a word such as "iOS" is not really in camel case <em>per se</em>; it defies <em>any</em>
    convention, so this recommendation does not apply.</li></ul></li><li>Now lowercase <em>everything</em> (including acronyms), then uppercase only the first
  character of:
  <ul><li>... each word, to yield <em>upper camel case</em>, or</li><li>... each word except the first, to yield <em>lower camel case</em></li></ul></li><li>Finally, join all the words into a single identifier.</li></ol><p>Note that the casing of the original words is almost entirely disregarded. Examples:</p><table><tbody><tr><th>Prose form</th><th>Correct</th><th>Incorrect</th></tr><tr><td>"XML HTTP request"</td><td><code class="prettyprint lang-java">XmlHttpRequest</code></td><td><code class="badcode">XMLHTTPRequest</code></td></tr><tr><td>"new customer ID"</td><td><code class="prettyprint lang-java">newCustomerId</code></td><td><code class="badcode">newCustomerID</code></td></tr><tr><td>"inner stopwatch"</td><td><code class="prettyprint lang-java">innerStopwatch</code></td><td><code class="badcode">innerStopWatch</code></td></tr><tr><td>"supports IPv6 on iOS?"</td><td><code class="prettyprint lang-java">supportsIpv6OnIos</code></td><td><code class="badcode">supportsIPv6OnIOS</code></td></tr><tr><td>"YouTube importer"</td><td><code class="prettyprint lang-java">YouTubeImporter</code><br><code class="prettyprint lang-java">YoutubeImporter</code>*</td><td></td></tr></tbody></table><p>*Acceptable, but not recommended.</p><p class="note"><strong>Note:</strong> Some words are ambiguously hyphenated in the English
language: for example "nonempty" and "non-empty" are both correct, so the method names
<code class="prettyprint lang-java">checkNonempty</code> and
<code class="prettyprint lang-java">checkNonEmpty</code> are likewise both correct.</p><a name="s6-programming-practices">
    </a><h2><a name="s6-programming-practices">6 Programming Practices&nbsp;</a><a href="#s6-programming-practices"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <a name="s6.1-override-annotation">
    </a><h3><a name="s6.1-override-annotation">6.1 @Override: always used&nbsp;</a><a href="#s6.1-override-annotation"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>A method is marked with the <code class="prettyprint lang-java">@Override</code> annotation
whenever it is legal.  This includes a class method overriding a superclass method, a class method
implementing an interface method, and an interface method respecifying a superinterface
method.</p><p class="exception"><strong>Exception:</strong><code class="prettyprint lang-java">@Override</code> may be omitted when the parent method is
<code class="prettyprint lang-java">@Deprecated</code>.</p><a name="caughtexceptions"></a><a name="s6.2-caught-exceptions">
    </a><h3><a name="s6.2-caught-exceptions">6.2 Caught exceptions: not ignored&nbsp;</a><a href="#s6.2-caught-exceptions"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>Except as noted below, it is very rarely correct to do nothing in response to a caught
exception. (Typical responses are to log it, or if it is considered "impossible", rethrow it as an
<code class="prettyprint lang-java">AssertionError</code>.)</p><p>When it truly is appropriate to take no action whatsoever in a catch block, the reason this is
justified is explained in a comment.</p><pre class="prettyprint lang-java">try {
  int i = Integer.parseInt(response);
  return handleNumericResponse(i);
} catch (NumberFormatException ok) {
  // it's not numeric; that's fine, just continue
}
return handleTextResponse(response);
</pre><p class="exception"><strong>Exception:</strong> In tests, a caught exception may be ignored
without comment <em>if</em> it is named <code class="prettyprint lang-java">expected</code>. The
following is a very common idiom for ensuring that the method under test <em>does</em> throw an
exception of the expected type, so a comment is unnecessary here.</p><pre class="prettyprint lang-java">try {
  emptyStack.pop();
  fail();
} catch (NoSuchElementException expected) {
}
</pre><a name="s6.3-static-members">
    </a><h3><a name="s6.3-static-members">6.3 Static members: qualified using class&nbsp;</a><a href="#s6.3-static-members"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>When a reference to a static class member must be qualified, it is qualified with that class's
name, not with a reference or expression of that class's type.</p><pre class="prettyprint lang-java">Foo aFoo = ...;
Foo.aStaticMethod(); // good
<span class="badcode">aFoo.aStaticMethod();</span> // bad
<span class="badcode">somethingThatYieldsAFoo().aStaticMethod();</span> // very bad
</pre><a name="finalizers"></a><a name="s6.4-finalizers">
    </a><h3><a name="s6.4-finalizers">6.4 Finalizers: not used&nbsp;</a><a href="#s6.4-finalizers"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>It is <strong>extremely rare</strong> to override <code class="prettyprint lang-java">Object.finalize</code>.</p><p class="tip"><strong>Tip:</strong> Don't do it. If you absolutely must, first read and understand
<a href="http://books.google.com/books?isbn=8131726592"><em>Effective Java</em></a>
Item 7, "Avoid Finalizers," very carefully, and <em>then</em> don't do it.</p><a name="javadoc"></a><a name="s7-javadoc">
    </a><h2><a name="s7-javadoc">7 Javadoc&nbsp;</a><a href="#s7-javadoc"><img height="21" width="21" src="javaguidelink.png"></a></h2>
    <a name="s7.1-javadoc-formatting">
    </a><h3><a name="s7.1-javadoc-formatting">7.1 Formatting&nbsp;</a><a href="#s7.1-javadoc-formatting"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <a name="s7.1.1-javadoc-multi-line">
    </a><h4><a name="s7.1.1-javadoc-multi-line">7.1.1 General form&nbsp;</a><a href="#s7.1.1-javadoc-multi-line"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>The <em>basic</em> formatting of Javadoc blocks is as seen in this example:</p><pre class="prettyprint lang-java">/**
 * Multiple lines of Javadoc text are written here,
 * wrapped normally...
 */
public int method(String p1) { ... }
</pre><p>... or in this single-line example:</p><pre class="prettyprint lang-java">/** An especially short bit of Javadoc. */
</pre><p>The basic form is always acceptable. The single-line form may be substituted when there are no
at-clauses present, and the entirety of the Javadoc block (including comment markers) can fit on a
single line.</p><a name="s7.1.2-javadoc-paragraphs">
    </a><h4><a name="s7.1.2-javadoc-paragraphs">7.1.2 Paragraphs&nbsp;</a><a href="#s7.1.2-javadoc-paragraphs"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>One blank line—that is, a line containing only the aligned leading asterisk
(<code>*</code>)—appears between paragraphs, and before the group of "at-clauses" if
present. Each paragraph but the first has <code>&lt;p&gt;</code> immediately before the first word,
with no space after.</p><a name="s7.1.3-javadoc-at-clauses">
    </a><h4><a name="s7.1.3-javadoc-at-clauses">7.1.3 At-clauses&nbsp;</a><a href="#s7.1.3-javadoc-at-clauses"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Any of the standard "at-clauses" that are used appear in the order <code>@param</code>,
<code>@return</code>, <code>@throws</code>, <code>@deprecated</code>, and these four types never
appear with an empty description. When an at-clause doesn't fit on a single line, continuation lines
are indented four (or more) spaces from the position of the <code>@</code>.
</p><a name="s7.2-summary-fragment">
    </a><h3><a name="s7.2-summary-fragment">7.2 The summary fragment&nbsp;</a><a href="#s7.2-summary-fragment"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>The Javadoc for each class and member begins with a brief <strong>summary fragment</strong>. This
fragment is very important: it is the only part of the text that appears in certain contexts such as
class and method indexes.</p><p>This is a fragment—a noun phrase or verb phrase, not a complete sentence. It does
<strong>not</strong> begin with <code class="badcode">A {@code Foo} is a...</code>, or
<code class="badcode">This method returns...</code>, nor does it form a complete imperative sentence
like <code class="badcode">Save the record.</code>. However, the fragment is capitalized and
punctuated as if it were a complete sentence.</p><p class="tip"><strong>Tip:</strong> A common mistake is to write simple Javadoc in the form
<code class="badcode">/** @return the customer ID */</code>. This is incorrect, and should be
changed to <code class="prettyprint lang-java">/** Returns the customer ID. */</code>.</p><a name="s7.3.3-javadoc-optional"></a><a name="s7.3-javadoc-where-required">
    </a><h3><a name="s7.3-javadoc-where-required">7.3 Where Javadoc is used&nbsp;</a><a href="#s7.3-javadoc-where-required"><img height="21" width="21" src="javaguidelink.png"></a></h3>
    <p>At the <em>minimum</em>, Javadoc is present for every
<code class="prettyprint lang-java">public</code> class, and every
<code class="prettyprint lang-java">public</code> or
<code class="prettyprint lang-java">protected</code> member of such a class, with a few exceptions
noted below.</p><p>Other classes and members still have Javadoc <em>as needed</em>.  Whenever an implementation
comment would be used to define the overall purpose or behavior of a class, method or field, that
comment is written as Javadoc instead. (It's more uniform, and more tool-friendly.)</p><a name="s7.3.1-javadoc-exception-self-explanatory">
    </a><h4><a name="s7.3.1-javadoc-exception-self-explanatory">7.3.1 Exception: self-explanatory methods&nbsp;</a><a href="#s7.3.1-javadoc-exception-self-explanatory"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Javadoc is optional for "simple, obvious" methods like
<code class="prettyprint lang-java">getFoo</code>, in cases where there <em>really and truly</em> is
nothing else worthwhile to say but "Returns the foo".</p><p class="note"><strong>Important:</strong> it is not appropriate to cite this exception to justify
omitting relevant information that a typical reader might need to know. For example, for a method
named <code class="prettyprint lang-java">getCanonicalName</code>, don't omit its documentation
(with the rationale that it would say only
<code class="badcode">/** Returns the canonical name. */</code>) if a typical reader may have no idea
what the term "canonical name" means!</p><a name="s7.3.2-javadoc-exception-overrides">
    </a><h4><a name="s7.3.2-javadoc-exception-overrides">7.3.2 Exception: overrides&nbsp;</a><a href="Google Java Style.html"><img height="21" width="21" src="javaguidelink.png"></a></h4>
    <p>Javadoc is not always present on a method that overrides a supertype method.
</p></div>  <hr>
  <div class="change">Last changed: March 21, 2014</div>


>>>>>>> .r3
</body></html>